On Fri, 27 Apr 2012 16:22:06 +0200, David Brown
<david@westcontrol.removethisbit.com> wrote:
>
>"Pedantic" means "particularly fussy or detailed". With gcc, using
>"pedantic" means that the compiler will be much stricter about
>supporting the standards, and /only/ the standards. For example,
>"restrict" and "inline" are keywords in later C standards, but were not
>available in earlier ones. gcc likes to give you more features than the
>standards demand, so that you can use these features when compiling in
>C89 mode. But to allow for people who happened to have a function
>called "restrict" and a typedef called "inline", which is legal in C89
>but not C99, you can compile in "pedantic" mode. (You can still access
>newer features as "__restrict__" or "__inline__" for example.)
>"pedantic" mode is also useful for checking strict standards
>compatibility to aid portability of code.
Thanks, now I understand.
Using www.dictionary.com, I got this:
1. ostentatious in one's learning.
2. overly concerned with minute details or formalisms, especially in
teaching.
The definition you provided is (I think) #2, and it wasn't clicking
for me by just reading the dictionary definition and the documentation
of the compiler parameter.
DTA
Reply by Christopher Head●April 27, 20122012-04-27
On Fri, 27 Apr 2012 16:41:52 +0200
Noob <root@127.0.0.1> wrote:
> He didn't provide the prototype of mul_32_96, but given the
> function call, one could assume
>
> void mul_32_96(uint32_t *in32, uint32_t *in96, uint32_t *mynum);
>
> where aliasing could indeed happen.
In that case it could. I assumed in96 was some kind of 96-bit-long
type, probably a struct. If they're all uint32_t pointers, then of
course they could alias.
Chris
Reply by Noob●April 27, 20122012-04-27
Christopher Head wrote:
> On Thu, 26 Apr 2012 22:59:09 +0200
> Hans-Bernhard Br�ker <HBBroeker@t-online.de> wrote:
>
>> I'm afraid you're overlooking the aliasing issue. Just because
>> _your_ function doesn't modify those values doesn't mean they won't
>> change mid-stride, which could actually _require_ the function to
>> keep reading the original value through the pointer.
>>
>> E.g. what do you think would happen if I did something (admittedly)
>> crazy equivalent to
>>
>> uint32_t mynum[10];
>> mul_32_96(/*in32*/mynum + i, /*in96*/ mynum + 1, /*out*/mynum);
>
> Doesn't the C strict aliasing rule make this unspecified behaviour?
> Pointers to different types neither of which are
> (signed|unsigned|blank) char and which aren't related by one being an
> element of the other are assumed not to alias.
He didn't provide the prototype of mul_32_96, but given the
function call, one could assume
void mul_32_96(uint32_t *in32, uint32_t *in96, uint32_t *mynum);
where aliasing could indeed happen.
Reply by Noob●April 27, 20122012-04-27
David T. Ashley wrote:
> Noob wrote:
>
>> AFAIR, gcc supports restrict even in (non-pedantic) C89 mode.
>
> Could you define "pedantic" in this usage?
>
> I looked up the word in a dictionary and also looked at compiler
> options, and the meaning of the word really isn't making sense to me.
>
> What is "pedantic"?
> On Thu, 26 Apr 2012 22:59:09 +0200
> Hans-Bernhard Bröker<HBBroeker@t-online.de> wrote:
>
>> I'm afraid you're overlooking the aliasing issue. Just because
>> _your_ function doesn't modify those values doesn't mean they won't
>> change mid-stride, which could actually _require_ the function to
>> keep reading the original value through the pointer.
>>
>> E.g. what do you think would happen if I did something (admittedly)
>> crazy equivalent to
>>
>> uint32_t mynum[10];
>> mul_32_96(/*in32*/mynum + i, /*in96*/ mynum + 1, /*out*/mynum);
>
> Doesn't the C strict aliasing rule make this unspecified behaviour?
> Pointers to different types neither of which are
> (signed|unsigned|blank) char and which aren't related by one being an
> element of the other are assumed not to alias.
>
> Chris
The types in question are 32-bit integers or arrays of 32-bit integers,
and these /are/ allowed to alias each other (AFAIUI).
mvh.,
David
Reply by David Brown●April 27, 20122012-04-27
On 27/04/2012 15:55, David T. Ashley wrote:
> On Fri, 27 Apr 2012 15:08:41 +0200, Noob<root@127.0.0.1> wrote:
>
>> David T. Ashley wrote:
>>
>>> I was not aware of the "restrict" keyword.
>>
>> cf. also http://en.wikipedia.org/wiki/Restrict
>>
>>> This is a C99 addition: http://en.wikipedia.org/wiki/C99
>>
>> Those who cannot afford the official standard may grab n1256.pdf
>>
>> http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
>>
>>> With some C90 compilers, I've seen various warning notes about
>>> enabling certain optimizations unless certain constraints on pointers
>>> were followed. This was apparently enough of a common occurrence that
>>> the "restrict" keyword showed up in C99 so that it could be handled in
>>> a more regular framework.
>>
>> AFAIR, gcc supports restrict even in (non-pedantic) C89 mode.
>
> Could you define "pedantic" in this usage?
>
> I looked up the word in a dictionary and also looked at compiler
> options, and the meaning of the word really isn't making sense to me.
>
> What is "pedantic"?
>
> Thanks, DTA
"Pedantic" means "particularly fussy or detailed". With gcc, using
"pedantic" means that the compiler will be much stricter about
supporting the standards, and /only/ the standards. For example,
"restrict" and "inline" are keywords in later C standards, but were not
available in earlier ones. gcc likes to give you more features than the
standards demand, so that you can use these features when compiling in
C89 mode. But to allow for people who happened to have a function
called "restrict" and a typedef called "inline", which is legal in C89
but not C99, you can compile in "pedantic" mode. (You can still access
newer features as "__restrict__" or "__inline__" for example.)
"pedantic" mode is also useful for checking strict standards
compatibility to aid portability of code.
Reply by David T. Ashley●April 27, 20122012-04-27
On Fri, 27 Apr 2012 15:08:41 +0200, Noob <root@127.0.0.1> wrote:
>David T. Ashley wrote:
>
>> I was not aware of the "restrict" keyword.
>
>cf. also http://en.wikipedia.org/wiki/Restrict
>
>> This is a C99 addition: http://en.wikipedia.org/wiki/C99
>
>Those who cannot afford the official standard may grab n1256.pdf
>
> http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
>
>> With some C90 compilers, I've seen various warning notes about
>> enabling certain optimizations unless certain constraints on pointers
>> were followed. This was apparently enough of a common occurrence that
>> the "restrict" keyword showed up in C99 so that it could be handled in
>> a more regular framework.
>
>AFAIR, gcc supports restrict even in (non-pedantic) C89 mode.
Could you define "pedantic" in this usage?
I looked up the word in a dictionary and also looked at compiler
options, and the meaning of the word really isn't making sense to me.
What is "pedantic"?
Thanks, DTA
Reply by Christopher Head●April 27, 20122012-04-27
> I'm afraid you're overlooking the aliasing issue. Just because
> _your_ function doesn't modify those values doesn't mean they won't
> change mid-stride, which could actually _require_ the function to
> keep reading the original value through the pointer.
>
> E.g. what do you think would happen if I did something (admittedly)
> crazy equivalent to
>
> uint32_t mynum[10];
> mul_32_96(/*in32*/mynum + i, /*in96*/ mynum + 1, /*out*/mynum);
Doesn't the C strict aliasing rule make this unspecified behaviour?
Pointers to different types neither of which are
(signed|unsigned|blank) char and which aren't related by one being an
element of the other are assumed not to alias.
Chris
> With some C90 compilers, I've seen various warning notes about
> enabling certain optimizations unless certain constraints on pointers
> were followed. This was apparently enough of a common occurrence that
> the "restrict" keyword showed up in C99 so that it could be handled in
> a more regular framework.
AFAIR, gcc supports restrict even in (non-pedantic) C89 mode.
Regards.
>
>I'm afraid you're overlooking the aliasing issue. Just because _your_
>function doesn't modify those values doesn't mean they won't change
>mid-stride, which could actually _require_ the function to keep reading
>the original value through the pointer.
>
>E.g. what do you think would happen if I did something (admittedly)
>crazy equivalent to
>
> uint32_t mynum[10];
> mul_32_96(/*in32*/mynum + i, /*in96*/ mynum + 1, /*out*/mynum);
>
>i.e. if one of the 4 words of output area is actually in the same place
>as your input? That way, as soon as you start writing into your output,
>the input might change under your nose. Note that 'const u32 *foo'
>doesn't really mean "pointer to an immutable value" --- it just means
>that you cannot change the underlying object object via this particular
>pointer. Const-qualified can point to quite non-const data.
>
>In case you ever read C99 language reference material and wondered what
>all that "restrict" business was about --- you've just found out.
Thanks for the info.
I was not aware of the "restrict" keyword. This is a C99 addition:
http://en.wikipedia.org/wiki/C99
With some C90 compilers, I've seen various warning notes about
enabling certain optimizations unless certain constraints on pointers
were followed. This was apparently enough of a common occurrence that
the "restrict" keyword showed up in C99 so that it could be handled in
a more regular framework.
OK, your post constitutes my training for the year. I try to learn
exactly one new thing every 365.25 days. I'll print this post and
send it to our HR person and I'm good until 2013 ...
DTA