Friday, August 9, 2019

Digest for comp.lang.c++@googlegroups.com - 25 updates in 6 topics

silidrone@gmail.com: Aug 09 09:37AM -0700

I saw a post with a code exactly the same as this (http://coliru.stacked-crooked.com/a/ac8e130d355d8f1e) one, and it said the output is "12 11" in the post. Now, that is the output I get when I run the code, but I don't see how there can be a specified output when C has no evaluation order of function parameters, am I missing something?
gazelle@shell.xmission.com (Kenny McCormack): Aug 09 04:54PM

In article <0fa0ca89-6e91-4f23-b025-74e50bb97646@googlegroups.com>,
>output is "12 11" in the post. Now, that is the output I get when I run the code,
>but I don't see how there can be a specified output when C has no evaluation
>order of function parameters, am I missing something?
 
Please post code here. That's the expected behavior for CLC posters.
 
We don't like to (in fact, some of us can't) follow arbitrary links.
 
--
Modern Conservative: Someone who can take time out from demanding more
flag burning laws, more abortion laws, more drug laws, more obscenity
laws, and more police authority to make warrantless arrests to remind
us that we need to "get the government off our backs".
porparek@gmail.com: Aug 09 09:30AM -0700

Hi,
 
Could you please explain me why capturing variables by value in a lambda is immutable by default ?
 
[=] () { ++ outsideVar; } (); // compilation error
 
I'm aware of "mutable" keyword in this scenario.
 
Best Regards
Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 06:52AM +0200

> not allowed without them.
> The fact that compilers have this kind of extension shows that using
> normal pointers for unaligned access is not supported!
 
It it ridiculous to believe that they support unaligned access through
this means but not by unaligned pointers.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 07:59AM +0200

>> normal pointers for unaligned access is not supported!
 
> It it ridiculous to believe that they support unaligned access through
> this means but not by unaligned pointers.
 
And even more: someone might argue that an unaligned attribute attached
to a data-type might result in a different kind of access suitable for
the architecture. But if you have a structure packed through #pragma
pack and take the address of an unaligned member the pointer will have
the same kind of unalignedness like if you would have done the math
yourself and calculated the address with pointer-arithmetics.
David Brown <david.brown@hesbynett.no>: Aug 09 09:19AM +0200

On 09/08/2019 07:59, Bonita Montero wrote:
>>> normal pointers for unaligned access is not supported!
 
>> It it ridiculous to believe that they support unaligned access through
>> this means but not by unaligned pointers.
 
Really? What possible reason could you have for that?
 
Do you also think it is ridiculous that compilers support wrapping
arithmetic through the means of unsigned types, but not through signed
types?
 
Do you also think it is ridiculous that compilers support multiplying by
4 by writing "x << 2", but not by writing "x >> -2" ?
 
What more silliness do you believe on the basis of "it worked when I
tried it" ?
 
 
> And even more: someone might argue that an unaligned attribute attached
> to a data-type might result in a different kind of access suitable for
> the architecture.
 
I am sure that anyone would expect that an unaligned attribute attached
to a data type (or more realistically, a pointer) would result in an
access suitable for unaligned access on that architecture. Whether or
not that means different instructions will depend on the architecture.
 
> pack and take the address of an unaligned member the pointer will have
> the same kind of unalignedness like if you would have done the math
> yourself and calculated the address with pointer-arithmetics.
 
If you have a packed struct, and you take the address of an unaligned
field in that struct and assign it to a normal pointer, you get an
unaligned pointer. The standards don't say if this is allowed or not,
since "packed" is not part of the standards, but they say clearly that
dereferencing that pointer is undefined behaviour. gcc will warn you
about this mistake (finally - it took them 7 years to get it in place).
I don't know if other compilers warn about this, ban it, or document
that it is allowed - you'd have to look up their documentation. But
there is no doubt at all that the behaviour is not defined by the standards.
 
Similarly, using pointer arithmetic, casts, etc, that give you an
unaligned pointer is likely to be undefined behaviour when the pointer
is assigned, and certainly undefined behaviour when it is used, unless
the compiler says it supports such code. And so far you have given
absolutely /no/ evidence to suggest that any compiler documents or
guarantees support for this kind of thing.
 
 
There is work in progress amongst the C and C++ workgroups about
formalising "pointer provenance". The aim is to provide compilers with
better information about pointer validity, and pointer and data aliasing
possibilities, leading to better static analysis and better
optimisation. I have already mentioned how link-time optimisation is
enhancing the flow of information within programs. The more you screw
around with clearly bad code that is explicitly disallowed by the
language, the greater your risks of having silent errors and hard to
find trouble in the future.
 
And what, exactly, do you gain from all this nonsense and risky
behaviour? Nothing, really.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 09:32AM +0200

> If you have a packed struct, and you take the address of an unaligned
> field in that struct and assign it to a normal pointer, you get an
> unaligned pointer.
 
That's the same kind of pointer you would get if you would have done
the math on your own and offsetted the address from the former member.
So there's not the least problem here.
 
> The standards don't say if this is allowed or not,
 
The standards are not relevant here.
We're talking about compiler-specific features.
 
> gcc will warn you about this mistake ...
 
That's not because it won't work but it's not portable to every
platform.
David Brown <david.brown@hesbynett.no>: Aug 09 10:14AM +0200

On 09/08/2019 09:32, Bonita Montero wrote:
 
> That's the same kind of pointer you would get if you would have done
> the math on your own and offsetted the address from the former member.
> So there's not the least problem here.
 
The problem is that it is wrong - whether you do the calculations
manually or by taking a pointer to the packed member.
 
>> The standards don't say if this is allowed or not,
 
> The standards are not relevant here.
 
What language are you using? I thought this was a group for a language
that has the advantage of a standardised definition, and a (reasonably)
clear set of rules. Perhaps you are more familiar with single-source
languages like Visual Basic or Delphi where the language is defined as
"whatever the tool does in this version".
 
> We're talking about compiler-specific features.
 
I'm /asking/ about compiler-specific features. You are making up stuff
as you go along, extrapolating from "it worked in this test". Give me a
reference to compiler documentation that says unaligned pointers are
acceptable coding on that tool, and I will happily agree that it is
valid on that compiler.
 
But you can't give such references. You can make wild claims about what
you think is valid, and about what you think all OS's do, but fail to
provide the slightest hint of evidence, references, or documentation to
back them up.
 
I've shown you the documentation that unaligned pointers and accesses
are undefined behaviour - they should not be used in code unless a
compiler gives you clear documentation and guarantees that they are
supported by that tool.
 
So now it is your turn - show your references to documentation, or
accept that you rely on luck for the validity of your code.
 
Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 10:21AM +0200

>> So there's not the least problem here.
 
> The problem is that it is wrong - whether you do the calculations
> manually or by taking a pointer to the packed member.
 
No, you would get the same adress and the same kind of pointer;
that is tha guarantee #pragma pack makes.
 
> What language are you using?
 
We're talking about the behaviour of specific implementations.
 
> a reference to compiler documentation that says unaligned pointers are
> acceptable coding on that tool, and I will happily agree that it is
> valid on that compiler.
 
The reference is simply the documentation on #pragma pack. If the
compiler wouldn't be able to allow unaligned access there would be
no #pragma pack.
David Brown <david.brown@hesbynett.no>: Aug 09 01:01PM +0200

On 09/08/2019 10:21, Bonita Montero wrote:
 
> The reference is simply the documentation on #pragma pack. If the
> compiler wouldn't be able to allow unaligned access there would be
> no #pragma pack.
 
So you don't understand the problem - you don't understand how the
language works, you don't understand how compilers work, you don't even
understand the concept of "documentation". You can't understand the
difference between how a compiler implements code and what code it
guarantees to support. You can't provide any justification or
references for your claims. You are happy to write pointlessly and
uselessly bad code, and to insist that wishful thinking is enough to
make it good.
 
I think we are done here.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 01:09PM +0200

> references for your claims. You are happy to write pointlessly and
> uselessly bad code, and to insist that wishful thinking is enough to
> make it good.
 
You don't understand why a compiler that supports #pragma pack has
reliable unaligned memory access. When I assign the address of an
unaligned member to a pointer that pointer hasnt special properties
that would help the compiler to access an unaligned value differently;
it's just the same kind of every pointer tothat type. So you can be
assured that a compiler that has #pragma pack has reliable unaligned
memory-access.
David Brown <david.brown@hesbynett.no>: Aug 09 03:38PM +0200

On 09/08/2019 13:09, Bonita Montero wrote:
>> make it good.
 
> You don't understand why a compiler that supports #pragma pack has
> reliable unaligned memory access.
 
I understand the compiler defines unaligned accesses when using packed
structs - I also understand that this says /nothing/ about what accesses
it supports through unaligned pointers. (Any support in the cpu
hardware is irrelevant.) Can't you understand the difference?
 
> it's just the same kind of every pointer tothat type. So you can be
> assured that a compiler that has #pragma pack has reliable unaligned
> memory-access.
 
No, you can't.
 
C and C++ are full of things that a naïve person might think make
obvious sense, and certainly could be implemented simply, but they are
still undefined behaviour. In some cases, compilers will assume that
you haven't done this kind of illegal coding, and optimise on that
basis. In most cases, such code works simply because it is less effort
to ignore the issue entirely than for the compiler to generate something
weird - but it does not prevent weird things from happening if
optimisations could be performed.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 03:45PM +0200

> C and C++ are full of things that a naïve person might think make
> obvious sense, and certainly could be implemented simply, but they
> are still undefined behaviour.
 
We are talking about compilers with #pragma packed support.
On these those things aren't undefined behaviour.
Robert Wessel <robertwessel2@yahoo.com>: Aug 09 09:37AM -0500

On Fri, 9 Aug 2019 15:45:44 +0200, Bonita Montero
>> are still undefined behaviour.
 
>We are talking about compilers with #pragma packed support.
>On these those things aren't undefined behaviour.
 
 
There is neither a requirement that #pragma pack has a particular
effect (which you are assuming is to byte align all structure
members), or that any pointer created that don't point to members of
such structure can actually be used if forced to pointed to someplace
unaligned. For example, I could see a compiler do a data flow
analysis to see if a pointer might possibly come from such an
unaligned structure member. An implementation might also use fat
pointers to have the same effect at runtime.
 
Probably preconditions both are true on most, perhaps even all,
compilers that implement #pragma pack(), but there's nothing, except
the implementation specific documentation, that defines that. You
might find some cross-platform documentation that applies (Posix* for
example) to the required behaviors.
 
David isn't saying that there are no implementations where what you're
doing works - he'd probably agree that there are many. Rather, that
you're making assumptions about which implementations support that
behavior, as well as *promise* to support that behavior, on an
inadequate basis.
 
 
*I don't actually know that Posix defines the behavior that you're
assuming (and I lack the interest to go look), but it might, just like
it guarantees 8-bit bytes.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 04:59PM +0200

> members), or that any pointer created that don't point to members of
> such structure can actually be used if forced to pointed to someplace
> unaligned.
 
Check your compiler-documentation.
It says that #pragma pack allows unaligned packing.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 05:04PM +0200

> Check your compiler-documentation.
> It says that #pragma pack allows unaligned packing.
 
MSVC-documentation:
"To pack a class is to place its members directly after each
other in memory, which can mean that some or all members can
be ligned on a boundary smaller than the default alignment
the target architecture"
gcc supports the same kind of #pragma pack, even with the
same push- / pop-syntax. According to the documentation this
is to be MSVC-compatible here.
Bart <bc@freeuk.com>: Aug 09 04:43PM +0100

On 09/08/2019 16:04, Bonita Montero wrote:
> gcc supports the same kind of #pragma pack, even with the
> same push- / pop-syntax. According to the documentation this
> is to be MSVC-compatible here.
 
Being able to define such a layout doesn't necessarily mean that
unaligned accesses are supported by hardware.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 09 07:41AM -0700

>> type floating point?).
 
> Is it true that it depends on the type of something in practical
> cases?
 
The short answer is yes. (more below)
 
> can't be done for every function. Of course, for mutual tail
> recursion I can't do that because of the non-local goto, but for
> the compiler that should also be easy.
 
I switch pretty easily (in C or C++) between functional style
code and imperative style code. So I routinely write small
functions using self-recursion, or sometimes mutual recursion
although that is less common. Of course I also want my code
to be practical so I do look at how the code is compiled,
sometimes with a visual inspection and sometimes using a
filter on the generated assembly to see where tail recursion
is compiled "badly", as a recursive call, rather than being
turned into a loop.
 
My experience is that direct tail recursion almost always[*] gets
turned into loops rather than recursive calls, if all the types
involved are scalar types (or references in C++). That also
holds for mutual recursion in cases where the functions involved
all have the same type (that is, the same return type and also
the same argument types, or at least "similar" argument types).
When the functions involved in a mutual recursion have different
numbers of arguments the results are not as reliable.
 
An important case that does *not* get compiled as iterative code
is when the return type is a struct (which I think also includes
unions). For some reason that happens even when the struct is
"simple", such as having only one member (and which has scalar
type). In C, using struct types for arguments is usually okay,
provided of course that they aren't too hairy. In C++, using
struct types for arguments often inhibits getting iterative
compiled code, even for "plain" structs. (Disclaimer: I haven't
explored what goes on when struct argument types are involved,
or more accurately I haven't explored it too deeply.)
 
On the flip side, a C++ case where recursion works great is
when constexpr functions are used to calculate constexpr
values. This property is important if one needs to write
constexpr functions that work in C++11 (and some people still
do), as in nearly all cases iterative code can be turned into
equivalent recursive code that adheres to the more restrictive
constraints for constexpr functions in C++11.
 
 
[*] Using gcc, clang, or g++, at optimization levels -Os/-O2 or
higher. Also, all the foregoing statements should be read as
most often true but not as absolutely true - there are always
the odd corner cases that can pop up, as with all things
programming.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 08:59AM +0200

Can anyone tell how a lock-free algorithm for a LRU-cache would
look like? LRU-caches are only possible with doubly-linked lists.
So I thought this woudn't be possible lock-free. But maybe I'm
wrong here and someone can give me an idea.
"Öö Tiib" <ootiib@hot.ee>: Aug 09 05:14AM -0700

On Friday, 9 August 2019 09:59:33 UTC+3, Bonita Montero wrote:
> look like? LRU-caches are only possible with doubly-linked lists.
> So I thought this woudn't be possible lock-free. But maybe I'm
> wrong here and someone can give me an idea.
 
One way is to add a thread that manages the cache.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 09 04:32PM +0200

>> So I thought this woudn't be possible lock-free. But maybe I'm
>> wrong here and someone can give me an idea.
 
> One way is to add a thread that manages the cache.
 
And that's lock-free??? ;-)
Melzzzzz <Melzzzzz@zzzzz.com>: Aug 09 02:38PM

>>> wrong here and someone can give me an idea.
 
>> One way is to add a thread that manages the cache.
 
> And that's lock-free??? ;-)
 
Take a look at Linux kernel...
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Frederick Gotham <cauldwell.thomas@gmail.com>: Aug 09 06:46AM -0700

Here's the *nix bash script I've got for the time being:
 
#!/bin/bash
 
EXTRA_COMPILER_FLAGS="-rdynamic -funwind-tables"
EXTRA_LINKER_FLAGS="-funwind-tables"
 
DIR1="/usr/bin/"
DIR1_FILE1="x86_64-linux-gnu-g++-7"
DIR1_FILE2="x86_64-linux-gnu-gcc-7"
DIR1_FILE3="x86_64-linux-gnu-ld.bfd"
 
DIR2="./toolchain/arm/bin/"
DIR2_FILE1="aarch64-linux-gnu-g++"
DIR2_FILE2="aarch64-linux-gnu-gcc"
DIR2_FILE3="aarch64-linux-gnu-ld"
 
if [[ $EUID -ne 0 ]]; then
echo "This script must be run as root"
exit 1
fi
 
if [ "$1" == "undo" ]; then
 
echo
echo "Undoing everything. . . "
echo
 
if [ -f "${DIR1}REAL_${DIR1_FILE1}" ]; then
rm -f "${DIR1}${DIR1_FILE1}"
mv "${DIR1}REAL_${DIR1_FILE1}" "${DIR1}${DIR1_FILE1}"
fi
 
if [ -f "${DIR1}REAL_${DIR1_FILE2}" ]; then
rm -f "${DIR1}${DIR1_FILE2}"
mv "${DIR1}REAL_${DIR1_FILE2}" "${DIR1}${DIR1_FILE2}"
fi
 
if [ -f "${DIR1}REAL_${DIR1_FILE3}" ]; then
rm -f "${DIR1}${DIR1_FILE3}"
mv "${DIR1}REAL_${DIR1_FILE3}" "${DIR1}${DIR1_FILE3}"
fi
 
if [ -f "${DIR2}REAL_${DIR2_FILE1}" ]; then
rm -f "${DIR2}${DIR2_FILE1}"
mv "${DIR2}REAL_${DIR2_FILE1}" "${DIR2}${DIR2_FILE1}"
fi
 
if [ -f "${DIR2}REAL_${DIR2_FILE2}" ]; then
rm -f "${DIR2}${DIR2_FILE2}"
mv "${DIR2}REAL_${DIR2_FILE2}" "${DIR2}${DIR2_FILE2}"
fi
 
if [ -f "${DIR2}REAL_${DIR2_FILE3}" ]; then
rm -f "${DIR2}${DIR2_FILE3}"
mv "${DIR2}REAL_${DIR2_FILE3}" "${DIR2}${DIR2_FILE3}"
fi
 
exit 0
fi
 
if [ -f "${DIR1}REAL_${DIR1_FILE1}" ]; then
echo "This script has already been run. It cannot be run a second time. You must do \"./replacer_script.sh undo\" first."
exit 1
fi
 
if [ ! -d "./toolchain" ]; then
echo "This script must be run from within the firmware directory, e.g. ~/svndir/illustra_amb_02_00, or ~/svndir/i825md_AMBARELLA"
exit 1
fi
 
FIRMWARE_DIR=`pwd`
 
echo "------------------------------------------------------------"
echo "FIRST TO REPLACE: x86_64 compilers in the directory /usr/bin"
echo "------------------------------------------------------------"
echo
 
echo "1: Navigating into directory: ${DIR1}"
echo
echo " $ cd ${DIR1}"
echo
cd ${DIR1}
 
echo "2: Renaming '${DIR1_FILE1}' to 'REAL_${DIR1_FILE1}'"
echo
echo " $ mv ${DIR1_FILE1} REAL_${DIR1_FILE1}"
echo
mv ${DIR1_FILE1} REAL_${DIR1_FILE1}
 
echo " Renaming '${DIR1_FILE2}' to 'REAL_${DIR1_FILE2}'"
echo
echo " $ mv ${DIR1_FILE2} REAL_${DIR1_FILE2}"
echo
mv ${DIR1_FILE2} REAL_${DIR1_FILE2}
 
echo " Renaming '${DIR1_FILE3}' to 'REAL_${DIR1_FILE3}'"
echo
echo " $ mv ${DIR1_FILE3} REAL_${DIR1_FILE3}"
echo
mv ${DIR1_FILE3} REAL_${DIR1_FILE3}
 
echo "3: Creating empty script '${DIR1_FILE1}' and enabling the execution flag"
echo
echo " $ touch ${DIR1_FILE1}"
echo " $ chmod +x ${DIR1_FILE1}"
echo
touch ${DIR1_FILE1}
chmod +x ${DIR1_FILE1}
 
echo " Creating empty script '${DIR1_FILE2}' and enabling the execution flag"
echo
echo " $ touch ${DIR1_FILE2}"
echo " $ chmod +x ${DIR1_FILE2}"
echo
touch ${DIR1_FILE2}
chmod +x ${DIR1_FILE2}
 
echo " Creating empty script '${DIR1_FILE3}' and enabling the execution flag"
echo
echo " $ touch ${DIR1_FILE3}"
echo " $ chmod +x ${DIR1_FILE3}"
echo
touch ${DIR1_FILE3}
chmod +x ${DIR1_FILE3}
 
echo "4: Adding two lines to each script"
echo
echo " $ echo \"echo \\\"REAL_${DIR1_FILE1} ${EXTRA_COMPILER_FLAGS} \\\$*\\\"\" > ${DIR1_FILE1}"
echo " $ echo \"REAL_${DIR1_FILE1} ${EXTRA_COMPILER_FLAGS} \\\$*\" >> ${DIR1_FILE1}"
echo "echo \"REAL_${DIR1_FILE1} ${EXTRA_COMPILER_FLAGS} \$*\"" > ${DIR1_FILE1}
echo "REAL_${DIR1_FILE1} ${EXTRA_COMPILER_FLAGS} \$*" >> ${DIR1_FILE1}
echo
echo " $ echo \"echo \\\"REAL_${DIR1_FILE2} ${EXTRA_COMPILER_FLAGS} \\\$*\\\"\" > ${DIR1_FILE2}"
echo " $ echo \"REAL_${DIR1_FILE2} ${EXTRA_COMPILER_FLAGS} \\\$*\" >> ${DIR1_FILE2}"
echo "echo \"REAL_${DIR1_FILE2} ${EXTRA_COMPILER_FLAGS} \$*\"" > ${DIR1_FILE2}
echo "REAL_${DIR1_FILE2} ${EXTRA_COMPILER_FLAGS} \$*" >> ${DIR1_FILE2}
echo
echo " $ echo \"if [[ \$* == *\"-shared\"* ]]; then\" > ${DIR1_FILE3}"
echo " $ echo \"echo \\\"REAL_${DIR1_FILE3} ${EXTRA_LINKER_FLAGS} \\\$*\\\"\" > ${DIR1_FILE3}"
echo " $ echo \"REAL_${DIR1_FILE3} ${EXTRA_LINKER_FLAGS} \\\$*\" >> ${DIR1_FILE3}"
echo " $ echo \"else\" >> ${DIR1_FILE3}"
echo " $ echo \"echo \\\"REAL_${DIR1_FILE3} \\\$*\\\"\" > ${DIR1_FILE3}"
echo " $ echo \"REAL_${DIR1_FILE3} \\\$*\" >> ${DIR1_FILE3}"
echo " $ echo \"fi\" >> ${DIR1_FILE3}"
echo "if [[ \$* == *\"-shared\"* ]]; then" > ${DIR1_FILE3}
echo "echo \"REAL_${DIR1_FILE3} ${EXTRA_LINKER_FLAGS} \$*\"" >> ${DIR1_FILE3}
echo "REAL_${DIR1_FILE3} ${EXTRA_LINKER_FLAGS} \$*" >> ${DIR1_FILE3}
echo "else" >> ${DIR1_FILE3}
echo "echo \"REAL_${DIR1_FILE3} \$*\"" >> ${DIR1_FILE3}
echo "REAL_${DIR1_FILE3} \$*" >> ${DIR1_FILE3}
echo "fi" >> ${DIR1_FILE3}
 
cd $FIRMWARE_DIR
 
echo "---------------------------------------------------------------"
echo "SECOND TO REPLACE: aarch64 compilers in the toolchain directory"
echo "---------------------------------------------------------------"
echo
echo "1: Navigating into directory: ${DIR2}"
echo
echo " $ cd ${DIR2}"
echo
cd ${DIR2}
 
echo "2: Renaming '${DIR2_FILE1}' to 'REAL_${DIR2_FILE1}'"
echo
echo " $ mv ${DIR2_FILE1} REAL_${DIR2_FILE1}"
echo
mv ${DIR2_FILE1} REAL_${DIR2_FILE1}
 
echo " Renaming '${DIR2_FILE2}' to 'REAL_${DIR2_FILE2}'"
echo
echo " $ mv ${DIR2_FILE2} REAL_${DIR2_FILE2}"
echo
mv ${DIR2_FILE2} REAL_${DIR2_FILE2}
 
echo " Renaming '${DIR2_FILE3}' to 'REAL_${DIR2_FILE3}'"
echo
echo " $ mv ${DIR2_FILE3} REAL_${DIR2_FILE3}"
echo
mv ${DIR2_FILE3} REAL_${DIR2_FILE3}
 
echo "3: Creating empty script '${DIR2_FILE1}' and enabling the execution flag"
echo
echo " $ touch ${DIR2_FILE1}"
echo " $ chmod +x ${DIR2_FILE1}"
echo
touch ${DIR2_FILE1}
chmod +x ${DIR2_FILE1}
 
echo " Creating empty script '${DIR2_FILE2}' and enabling the execution flag"
echo
echo " $ touch ${DIR2_FILE2}"
echo " $ chmod +x ${DIR2_FILE2}"
echo
touch ${DIR2_FILE2}
chmod +x ${DIR2_FILE2}
 
echo " Creating empty script '${DIR2_FILE3}' and enabling the execution flag"
echo
echo " $ touch ${DIR2_FILE3}"
echo " $ chmod +x ${DIR2_FILE3}"
echo
touch ${DIR2_FILE3}
chmod +x ${DIR2_FILE3}
 
echo "4: Adding two lines to each script"
echo
echo " $ echo \"echo \\\"${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE1} ${EXTRA_COMPILER_FLAGS} \\\$*\\\"\" > ${DIR2_FILE1}"
echo " $ echo \"${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE1} ${EXTRA_COMPILER_FLAGS} \\\$*\" >> ${DIR2_FILE1}"
echo "echo \"${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE1} ${EXTRA_COMPILER_FLAGS} \$*\"" > ${DIR2_FILE1}
echo "${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE1} ${EXTRA_COMPILER_FLAGS} \$*" >> ${DIR2_FILE1}
echo
echo " $ echo \"echo \\\"${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE2} ${EXTRA_COMPILER_FLAGS} \\\$*\\\"\" > ${DIR2_FILE2}"
echo " $ echo \"${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE2} ${EXTRA_COMPILER_FLAGS} \\\$*\" >> ${DIR2_FILE2}"
echo "echo \"${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE2} ${EXTRA_COMPILER_FLAGS} \$*\"" > ${DIR2_FILE2}
echo "${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE2} ${EXTRA_COMPILER_FLAGS} \$*" >> ${DIR2_FILE2}
echo
echo " $ echo \"if [[ \$* == *\"-shared\"* ]]; then\" > ${DIR2_FILE3}"
echo " $ echo \"echo \\\"${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE3} ${EXTRA_LINKER_FLAGS} \\\$*\\\"\" > ${DIR2_FILE3}"
echo " $ echo \"${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE3} ${EXTRA_LINKER_FLAGS} \\\$*\" >> ${DIR2_FILE3}"
echo " $ echo \"else\" >> ${DIR2_FILE3}"
echo " $ echo \"echo \\\"${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE3} \\\$*\\\"\" > ${DIR2_FILE3}"
echo " $ echo \"${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE3} \\\$*\" >> ${DIR2_FILE3}"
echo " $ echo \"fi\" >> ${DIR2_FILE3}"
echo "if [[ \$* == *\"-shared\"* ]]; then" > ${DIR2_FILE3}
echo "echo \"${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE3} ${EXTRA_LINKER_FLAGS} \$*\"" >> ${DIR2_FILE3}
echo "${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE3} ${EXTRA_LINKER_FLAGS} \$*" >> ${DIR2_FILE3}
echo "else" >> ${DIR2_FILE3}
echo "echo \"${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE3} \$*\"" >> ${DIR2_FILE3}
echo "${FIRMWARE_DIR}/${DIR2}/REAL_${DIR2_FILE3} \$*" >> ${DIR2_FILE3}
echo "fi" >> ${DIR2_FILE3}
echo
 
cd $FIRMWARE_DIR
Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 09 02:01PM

On Thu, 2019-08-08, Scott Lurndal wrote:
 
> Why? Doesn't seem completely out-of-line:
 
> $ find bootloader firmware -name Makefile | wc -l
> 929
 
Because I believe in the Recursive Make Considered Harmful paper:
http://aegis.sourceforge.net/auug97.pdf
 
> If you're also building linux:
> $ find linux -name Makefile | wc -l
> 2064
 
IIRC, Linux falls into the next category:
 
>>(I'm assuming you're not just seeing the internals of cmake or a
>>similar tool auto-generating a gazillion makefiles.)
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
scott@slp53.sl.home (Scott Lurndal): Aug 09 02:36PM

>> 929
 
>Because I believe in the Recursive Make Considered Harmful paper:
>http://aegis.sourceforge.net/auug97.pdf
 
That paper has never been convincing to me, nor anyone that I've
ever worked with, nor any unix or linux os or other large sourcebase
that I've worked on professionally.
 
 
>IIRC, Linux falls into the next category:
 
>>>(I'm assuming you're not just seeing the internals of cmake or a
>>>similar tool auto-generating a gazillion makefiles.)
 
You do not recall correctly. kernel makefiles are not generated.
 
scott
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)