Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #103611 > unrolled thread

Is 'extern' necessary?

Back to article view | Back to comp.lang.c

Contents

  Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 17:16 +0000
    Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-10 09:33 -0800
      Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 18:41 +0000
        Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-10 12:09 -0800
          Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 20:29 +0000
            Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-10 13:26 -0800
              Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 22:56 +0000
                Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-10 20:19 -0800
                  Re: Is 'extern' necessary? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-11 09:53 -0500
                Re: Is 'extern' necessary? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-13 05:19 -0800
        Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-10 12:09 -0800
          Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 20:50 +0000
            Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-10 13:09 -0800
            Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-10 13:33 -0800
            Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 23:23 +0000
              Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 23:35 +0000
                Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-11 00:34 +0000
              Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-13 12:41 +0100
                Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-13 13:14 +0000
                  Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-13 14:05 +0000
                  Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-13 07:49 -0800
            Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-10 19:33 -0800
              Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-11 09:41 -0800
                Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-11 10:19 -0800
                  Re: Is 'extern' necessary? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-11 13:39 -0500
                  Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-12 10:10 -0800
        Re: Is 'extern' necessary? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-10 14:59 -0800
        Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-13 12:33 +0100
    Re: Is 'extern' necessary? Siri Cruise <chine.bleu@yahoo.com> - 2017-02-10 09:35 -0800
      Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-10 12:12 -0800
    Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-10 10:38 -0800
    Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 21:10 +0000
      Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-10 13:25 -0800
    Re: Is 'extern' necessary? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-10 14:53 -0800
      Re: Is 'extern' necessary? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-10 15:06 -0800
      Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 23:24 +0000
        Re: Is 'extern' necessary? Ian Collins <ian-news@hotmail.com> - 2017-02-11 12:34 +1300
          Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-13 13:14 +0100
            Re: Is 'extern' necessary? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-13 13:44 +0100
              Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-13 14:13 +0000
              Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-13 15:16 +0100
                Re: Is 'extern' necessary? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-13 17:24 +0100
                  Re: Is 'extern' necessary? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-13 14:24 -0500
                  Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-13 23:29 +0100
              Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-13 11:06 -0800
              Re: Is 'extern' necessary? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-13 11:15 -0800
            Re: Is 'extern' necessary? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-13 11:48 -0500
              Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-13 09:03 -0800
              Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-13 23:37 +0100
        Re: Is 'extern' necessary? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-10 15:40 -0800
        Re: Is 'extern' necessary? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-13 05:09 -0800
          Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-13 13:46 +0000
            Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-13 09:52 -0800
              Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-13 19:19 +0000
                Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-13 11:34 -0800
                  Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-13 20:13 +0000
                Re: Is 'extern' necessary? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-13 13:11 -0800
                Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-14 00:33 +0100
                  Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-14 01:02 +0000
                    Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-14 09:28 +0100
                      Re: Is 'extern' necessary? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-14 03:31 -0600
                      Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-14 11:42 +0000
                        Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-14 13:29 +0100
                          Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-14 05:16 -0800
                            Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-14 14:51 +0100
                              Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-14 07:24 -0800
                                Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-14 21:35 +0100
                                  Re: Is 'extern' necessary? James Kuyper <jameskuyper@verizon.net> - 2017-02-14 15:53 -0500
                                    Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-15 09:31 +0100
                                      Re: Is 'extern' necessary? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-15 11:36 -0500
                                        Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-15 09:12 -0800
                                          Re: Is 'extern' necessary? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-15 12:58 -0500
                                        Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-15 10:01 -0800
                                          Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-15 10:55 -0800
                                            Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-15 11:42 -0800
                                              Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-15 12:28 -0800
                                                Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-15 13:58 -0800
                            Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-14 08:54 -0800
                        Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-14 08:51 -0800
                          Re: Is 'extern' necessary? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-14 17:32 +0000
                            Re: Is 'extern' necessary? Gareth Owen <gwowen@gmail.com> - 2017-02-14 17:45 +0000
                          Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-14 21:38 +0100
                          Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-14 23:26 +0000
                            Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-14 16:33 -0800
                              Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-15 00:47 +0000
                        Re: Is 'extern' necessary? Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-14 18:17 +0100
                          Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-14 09:47 -0800
                            Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-14 18:36 +0000
                              Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-14 11:20 -0800
                              Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-14 11:42 -0800
                                Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-14 20:22 +0000
                              Re: Is 'extern' necessary? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-14 17:58 -0600
                                Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-15 01:29 +0000
                                  Re: Is 'extern' necessary? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-16 05:02 -0600
                                    Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-16 11:38 +0000
                                      Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-16 14:37 +0000
                                        Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-16 15:43 +0000
                                          Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-16 16:08 +0000
                                      Re: Is 'extern' necessary? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-16 18:42 +0100
                                Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-15 09:47 +0100
                                  Re: Is 'extern' necessary? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-16 05:05 -0600
            Re: Is 'extern' necessary? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-15 16:53 -0800
      Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 23:55 +0000
    Re: Is 'extern' necessary? Les Cargill <lcargill99@comcast.com> - 2017-02-10 19:24 -0600
    Re: Is 'extern' necessary? void <nathan.gothier@gmail.com> - 2017-02-11 03:17 -0800

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#103861

On Tue, 14 Feb 2017 09:28:50 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>Standard library code is part of the implementation.  Even if it is
>developed separately from the compiler, it is still in close cooperation
>with the compiler.  It does not have to follow the rules - it can
>"cheat", as long as the compiler is in on the game - the library writer
>can put things in the headers and implementation files that are not
>allowed in user code.  It is written by a few people, but used by
>millions - the emphasis is very solidly on the side of run-time
>efficiency rather than developer efficiency.  It must work regardless of
>the compiler options, and usually regardless of the compiler version -
>sometimes regardless of the compiler vendor.  It typically must work
>regardless of the language, supporting C and C++ and possibly others
>such as Objective-C.  And it must match the standards exactly.


And there are places where the implementation is *required* to
"cheat".  The implementation of the offsetof macro, for example.

[toc] | [prev] | [next] | [standalone]

#103867

On 14/02/2017 08:28, David Brown wrote:
> On 14/02/17 02:02, BartC wrote:
>> On 13/02/2017 23:33, David Brown wrote:
>>> On 13/02/17 20:19, BartC wrote:
>>
>>>> It's a mystery why gcc-related headers seem to be so full of junk
>>>> compared with those of other compilers.
>>>
>>> Basically, what you are saying is "I don't understand this.  Therefore
>>> it must be junk".  I don't know whether you are too lazy to look it up,
>>
>> Why would I want to look it up?
>
> You must have had some interest in the details to look up the function's
> declaration in the header file - otherwise you would do what everyone
> else does, and use a more practical reference for the vsnprintf
> function, such as:
>
> <http://en.cppreference.com/w/c/io/vfprintf>
>
> So you are interested in how it is declared, yet now you are saying that
> you are not interested in what these details mean.

You should have read from further up the thread. I was investigating the 
use of 'extern' in various headers, and came across this.

It's like looking to see what kind of plugs are used in the sockets for 
various appliances, and coming across various 'christmas tree' 
arrangements with a dozen plugs plugged into one socket via multiple 
adaptors. You're not interested in what those extra plugs are for, only 
that it looks wrong.

>> Look at the lccwin or MSDN versions
>> below; /that's/ how you want these things expressed. Short and sweet. (I
>> don't want to think about what your own headers look like if you think
>> this is reasonable.)
>
> I don't have lccwin or MSDN, and have no interest in them - so no, I
> won't look that up.  You posted lccwin's version and it is far inferior
> for a library call.  It does not follow the standards (at least, not C99
> onwards),

Actually it's closer to what is given in the C standard than MingW's 
version.

  it does not name the parameters,

What's the purpose of that? If you say human documentation, then you're 
having a laugh. For some reason or other, they're putting half of the 
gubbins needed to implement it into the public interface.

  it provides no extra
> information to the compiler for optimisation usage (maybe lccwin simply
> does not have the same kind of optimisations),

This is at odds with what you've always said in the past about keeping 
explicit optimisation hints out of the source code, and letting the 
compiler just do its job.

  and it does not provide
> information to allow the kind of extremely useful format checking
> features of gcc.

I've already said that lccwin does exactly the same kind of format-checking.

> Standard library code is part of the implementation.  Even if it is
> developed separately from the compiler, it is still in close cooperation
> with the compiler.

"The" compiler? I thought such libraries were completely independent 
from any one compiler and were all interchangable?

Or you finally admitting that perhaps the MingW library /is/ really 
designed to work with gcc?


> The "vsnprintf" function is defined in the standard - the compiler knows
> what it should do, and can check the format string.  Whether it does
> that or not, I don't know.

So what's the point of the 'format' stuff then in the MingW code?

> int main(void) {
>   int a = 1;
>   const char* s = "Hello";
>   printf("Text: %s Data: %i\n", a, s);
> }
>
> With -Wall, gcc will warn that "%s" expects an argument of type "char*",
> but argument 2 has type "int".
>
> Does lccwin do that kind of checking?

lccwin gives me this with default options:

Warning c.c: 5  printf argument mismatch for format s. Expected char 
pointer got int
Warning c.c: 5  printf argument mismatch for format i. Expected int got 
pointer to char

gcc says nothing with default options. gcc -pedantic-errors says 
nothing. I have to use one of the -Wxxx options to get it to report it. 
So not only do I need the macguffin in the header file, I need a 
counterpart in the compiler options.

(Actually I tried to comment out the format attribute stuff from stdio.h 
to see if gcc still managed it. But it's so complicated I can hardly 
find the printf declaration. I completely commented out what looks like 
the one, and it still worked. It didn't even give an 'implicit 
declaration of printf' warning. So it's seeing it somewhere, but where? 
Hiding the stdio.h file did give an error about not finding stdio.h, so 
it was the right file; it wasn't sneakily using a version elsewhere.

THIS is what it's all about; when things get sticky enough that you have 
to start investigating things, then gcc or anything associated with it 
makes it much harder than with any other compiler (msvc excepted).

But perhaps that's to be expected with a compiler that chooses path 
names so difficult to type that you usually have to copy&paste:

   \tdm\x86_64-w64-mingw32\include

and with a back-up include path for the standard headers it can't find 
there:

  \tdm\lib\gcc\x86_64-w64-mingw32\5.1.0\include)

   As I say, it is perfectly
> possible for the compiler to manage this without it being in the header.

You make it sound like a dog walking on its hind legs. Of course it can 
do it if a compiler 'knows' about *printf functions.


-- 
bartc

[toc] | [prev] | [next] | [standalone]

#103873

On 14/02/17 12:42, BartC wrote:
> On 14/02/2017 08:28, David Brown wrote:
>> On 14/02/17 02:02, BartC wrote:
>>> On 13/02/2017 23:33, David Brown wrote:
>>>> On 13/02/17 20:19, BartC wrote:
>>>
>>>>> It's a mystery why gcc-related headers seem to be so full of junk
>>>>> compared with those of other compilers.
>>>>
>>>> Basically, what you are saying is "I don't understand this.  Therefore
>>>> it must be junk".  I don't know whether you are too lazy to look it up,
>>>
>>> Why would I want to look it up?
>>
>> You must have had some interest in the details to look up the function's
>> declaration in the header file - otherwise you would do what everyone
>> else does, and use a more practical reference for the vsnprintf
>> function, such as:
>>
>> <http://en.cppreference.com/w/c/io/vfprintf>
>>
>> So you are interested in how it is declared, yet now you are saying that
>> you are not interested in what these details mean.
> 
> You should have read from further up the thread. I was investigating the
> use of 'extern' in various headers, and came across this.

Fair enough.

> 
> It's like looking to see what kind of plugs are used in the sockets for
> various appliances, and coming across various 'christmas tree'
> arrangements with a dozen plugs plugged into one socket via multiple
> adaptors. You're not interested in what those extra plugs are for, only
> that it looks wrong.

The difference here is that you know enough about plugs to know that
this is a bad idea.  But with the variety of attributes and qualifiers
in this header, /you/ don't know enough about them to judge if they are
appropriate or not.  All you can say is that it offends your aesthetic
sense of code that looks nice - which is, of course, irrelevant in such
internal code that is meant to be read by the compiler, not the programmer.

> 
>>> Look at the lccwin or MSDN versions
>>> below; /that's/ how you want these things expressed. Short and sweet. (I
>>> don't want to think about what your own headers look like if you think
>>> this is reasonable.)
>>
>> I don't have lccwin or MSDN, and have no interest in them - so no, I
>> won't look that up.  You posted lccwin's version and it is far inferior
>> for a library call.  It does not follow the standards (at least, not C99
>> onwards),
> 
> Actually it's closer to what is given in the C standard than MingW's
> version.

It does not have "restrict".  There is nothing to stop an implementation
/adding/ information - but it should not skip things.

> 
>  it does not name the parameters,
> 
> What's the purpose of that? If you say human documentation, then you're
> having a laugh. For some reason or other, they're putting half of the
> gubbins needed to implement it into the public interface.

Let us then say it is for inhuman documentation - for use by those weird
creatures that are able to read reference manuals, use google, think,
and in other ways understand the way the declaration is written.  It is
also for IDEs that can show the parameter names as hints while typing,
or documentation generators like doxygen that can digest the header to
generate more human-friendly information.

> 
>  it provides no extra
>> information to the compiler for optimisation usage (maybe lccwin simply
>> does not have the same kind of optimisations),
> 
> This is at odds with what you've always said in the past about keeping
> explicit optimisation hints out of the source code, and letting the
> compiler just do its job.

No, you must have misunderstood me.  My principle is to give the
compiler as much information as possible, then let it generate the best
code it can.  I advise against trying to do "hand optimisation" (or
inventing constructs for hand optimisation when designing a new
language).  But if you can give the compiler more information, then it
can do a better job of optimising and also static error checking.

> 
>  and it does not provide
>> information to allow the kind of extremely useful format checking
>> features of gcc.
> 
> I've already said that lccwin does exactly the same kind of
> format-checking.

I don't have experience with lccwin, so I can't comment (except as I
have done earlier about how this could be implemented).

> 
>> Standard library code is part of the implementation.  Even if it is
>> developed separately from the compiler, it is still in close cooperation
>> with the compiler.
> 
> "The" compiler? I thought such libraries were completely independent
> from any one compiler and were all interchangable?
> 
> Or you finally admitting that perhaps the MingW library /is/ really
> designed to work with gcc?

Standard libraries are never going to be /completely/ independent or
interchangeable - but they certainly can be somewhat independent.  It
might be that the library you have here only works with the particular
build of gcc that you have, but it is certainly common that a library
used for gcc will work on a range of gcc targets and sizes, different
gcc versions, different C standards, and likely also at least clang.  It
could perhaps also work with Intel's icc, maybe Pathscale, and other
*nix compilers.  You can read up about various standard library
implementations and how portable they are.

So I should have written "compilers", rather than "the compiler".

> 
> 
>> The "vsnprintf" function is defined in the standard - the compiler knows
>> what it should do, and can check the format string.  Whether it does
>> that or not, I don't know.
> 
> So what's the point of the 'format' stuff then in the MingW code?

That is gcc's (and clang's, and maybe other compilers') method of
telling the compiler that this is a printf-style function, and which
parameters are to be used for format checking.  This means that gcc can
support a single attribute and method, and use it for any such function.
 It is an alternative to hard-coding the functionality in the compiler.

> 
>> int main(void) {
>>   int a = 1;
>>   const char* s = "Hello";
>>   printf("Text: %s Data: %i\n", a, s);
>> }
>>
>> With -Wall, gcc will warn that "%s" expects an argument of type "char*",
>> but argument 2 has type "int".
>>
>> Does lccwin do that kind of checking?
> 
> lccwin gives me this with default options:
> 
> Warning c.c: 5  printf argument mismatch for format s. Expected char
> pointer got int
> Warning c.c: 5  printf argument mismatch for format i. Expected int got
> pointer to char
> 

Marvellous.  I am a big fan of doing as much static error checking as
practically possible.

> gcc says nothing with default options. gcc -pedantic-errors says
> nothing. I have to use one of the -Wxxx options to get it to report it.
> So not only do I need the macguffin in the header file, I need a
> counterpart in the compiler options.

Well, yes.  The code is allowed to have such mismatches.  gcc is an
extremely flexible tool, and people use it in a wide variety of ways.
Some people want lots of warnings, some people want none.  Some people
want optimisations, others want none.  And so on.  lccwin is a more
niche tool, and is very much the product of one person - the way it
works and the default functionality is picked according to what Jacob
thinks is good.  Now, I happen to agree with him that enabling warnings
by default is a good thing.  But there are a gazilion gcc users out
there, and each will have a different opinion on which combination of
gcc warnings is best.  So you specify it on the command line.


> 
> (Actually I tried to comment out the format attribute stuff from stdio.h
> to see if gcc still managed it. But it's so complicated I can hardly
> find the printf declaration. I completely commented out what looks like
> the one, and it still worked. It didn't even give an 'implicit
> declaration of printf' warning. So it's seeing it somewhere, but where?
> Hiding the stdio.h file did give an error about not finding stdio.h, so
> it was the right file; it wasn't sneakily using a version elsewhere.

It turns out that gcc will check the format identifiers for printf even
without including <stdio.h> at all.  Whether it will do that with
vsnprintf or not, I haven't tested - it might well do so.  But perhaps
the library authors are aware of issues that we are not.  Maybe earlier
versions of gcc (for which this library is still valid) need it, perhaps
other compilers need it, perhaps it is needed when using different
compiler flags, or perhaps the authors simply felt it was the correct
thing to do - put the format attribute in explicitly.

> 
> THIS is what it's all about; when things get sticky enough that you have
> to start investigating things, then gcc or anything associated with it
> makes it much harder than with any other compiler (msvc excepted).

You have demonstrated clearly that /you/ think it is hard, but nothing
you have written makes it appear hard to me.  And nothing indicates that
any of this is relevant to your average C programmer who simply uses
these functions without bothering about the details.

> 
> But perhaps that's to be expected with a compiler that chooses path
> names so difficult to type that you usually have to copy&paste:
> 
>   \tdm\x86_64-w64-mingw32\include
> 
> and with a back-up include path for the standard headers it can't find
> there:
> 
>  \tdm\lib\gcc\x86_64-w64-mingw32\5.1.0\include)
> 

You are complaining about path names?  The name (which is chosen by the
people building your mingw copy, it is not fixed by gcc) conveniently
shows target and version numbers.  As someone who has many compilers for
many targets and with many versions, I am very glad to see such names.
If I don't want to type them, copy and paste works as does tab
completion, or selection from a file browser.  Certainly such names are
vastly easier to work with than some monstrosity under "Program Files
(x86)".

>   As I say, it is perfectly
>> possible for the compiler to manage this without it being in the header.
> 
> You make it sound like a dog walking on its hind legs. Of course it can
> do it if a compiler 'knows' about *printf functions.
> 
> 

[toc] | [prev] | [next] | [standalone]

#103877

On Tuesday, February 14, 2017 at 6:29:50 AM UTC-6, David Brown wrote:
> It does not have "restrict".  There is nothing to stop an implementation
> /adding/ information - but it should not skip things.

Does "restrict" serve any more purpose in a prototype than identifier names?
It would be possible to define qualifiers somewhat similar to "restrict"
which would supply useful information to a caller about how a parameter would
be used (e.g. qualifiers saying that any pointer passed into a function would
not be persisted thereby, or saying that it would be persisted--if at all--
*only* in the return value, could allow some easy and useful caller-side
optimizations when given the address of something whose address was not other-
wise exposed to the outside world).  The "restrict" qualifier, however, is
not defined in a way that imparts any useful information I can see to the
caller.

[toc] | [prev] | [next] | [standalone]

#103881

On 14/02/17 14:16, supercat@casperkitty.com wrote:
> On Tuesday, February 14, 2017 at 6:29:50 AM UTC-6, David Brown wrote:
>> It does not have "restrict".  There is nothing to stop an implementation
>> /adding/ information - but it should not skip things.
> 
> Does "restrict" serve any more purpose in a prototype than identifier names?

I suppose its main purpose is documentary, like identifier names - it
tells the user that these pointers should be distinct and will be
treated that way in the function body.  It could also be used for static
error checking - the complier could issue a warning or error if it could
see that the restricted pointers overlap.

> It would be possible to define qualifiers somewhat similar to "restrict"
> which would supply useful information to a caller about how a parameter would
> be used (e.g. qualifiers saying that any pointer passed into a function would
> not be persisted thereby, or saying that it would be persisted--if at all--
> *only* in the return value, could allow some easy and useful caller-side
> optimizations when given the address of something whose address was not other-
> wise exposed to the outside world).  The "restrict" qualifier, however, is
> not defined in a way that imparts any useful information I can see to the
> caller.
> 

[toc] | [prev] | [next] | [standalone]

#103884

On Tuesday, February 14, 2017 at 7:51:49 AM UTC-6, David Brown wrote:
> I suppose its main purpose is documentary, like identifier names - it
> tells the user that these pointers should be distinct and will be
> treated that way in the function body.  It could also be used for static
> error checking - the complier could issue a warning or error if it could
> see that the restricted pointers overlap.

In what cases could a compiler meaningfully offer such warnings without being
able to see into the function in question?  If it can see into the function in
question, the existence or absence of "restrict" in the declaration would be
irrelevant.  Since "restrict" does have a documentary purpose similar to names,
it may be helpful for an implementation which includes names to include the
"restrict" as well, but if its purpose is solely documentary I see no reason
to include it in a prototype whose purpose is solely functional.

[toc] | [prev] | [next] | [standalone]

#103907

On 14/02/17 16:24, supercat@casperkitty.com wrote:
> On Tuesday, February 14, 2017 at 7:51:49 AM UTC-6, David Brown wrote:
>> I suppose its main purpose is documentary, like identifier names - it
>> tells the user that these pointers should be distinct and will be
>> treated that way in the function body.  It could also be used for static
>> error checking - the complier could issue a warning or error if it could
>> see that the restricted pointers overlap.
>
> In what cases could a compiler meaningfully offer such warnings without being
> able to see into the function in question?  If it can see into the function in
> question, the existence or absence of "restrict" in the declaration would be
> irrelevant.  Since "restrict" does have a documentary purpose similar to names,
> it may be helpful for an implementation which includes names to include the
> "restrict" as well, but if its purpose is solely documentary I see no reason
> to include it in a prototype whose purpose is solely functional.
>

If you have:

extern void foo(int * restrict a, int * restrict b);

and

void bar(int * c) {
	foo(c, c);
}

then the compiler would know there is something bad going on, and could 
warn about it.  It would only work in a few cases - the compiler has no 
way of knowing if "foo(c, c + 1)" is valid or not.

[toc] | [prev] | [next] | [standalone]

#103909

On 02/14/2017 03:35 PM, David Brown wrote:
...
> If you have:
> 
> extern void foo(int * restrict a, int * restrict b);
> 
> and
> 
> void bar(int * c) {
> 	foo(c, c);
> }
> 
> then the compiler would know there is something bad going on, and could 
> warn about it.  It would only work in a few cases - the compiler has no 
> way of knowing if "foo(c, c + 1)" is valid or not.

If foo() only ever accesses a[i] for even values of i, and b[i] only for
odd values of i, then foo(c,c) would be perfectly fine, and foo(c,c+1)
would not.

[toc] | [prev] | [next] | [standalone]

#103920

On 14/02/17 21:53, James Kuyper wrote:
> On 02/14/2017 03:35 PM, David Brown wrote:
> ...
>> If you have:
>>
>> extern void foo(int * restrict a, int * restrict b);
>>
>> and
>>
>> void bar(int * c) {
>> 	foo(c, c);
>> }
>>
>> then the compiler would know there is something bad going on, and could 
>> warn about it.  It would only work in a few cases - the compiler has no 
>> way of knowing if "foo(c, c + 1)" is valid or not.
> 
> If foo() only ever accesses a[i] for even values of i, and b[i] only for
> odd values of i, then foo(c,c) would be perfectly fine, and foo(c,c+1)
> would not.
> 

Good point.

I suppose that even in the case:

void bar2(int c) {
	foo(&c, &c);
}

then even though the only legal access through "a" and "b" is the same
object "c", it is quite possible that foo does not access both of them.

I can't think of any more possible warnings, nor any possible
optimisations, that the compiler could make simply from knowing that the
two arguments to "foo" are marked "restrict".

[toc] | [prev] | [next] | [standalone]

#103945

On 02/15/2017 03:31 AM, David Brown wrote:
> On 14/02/17 21:53, James Kuyper wrote:
>> On 02/14/2017 03:35 PM, David Brown wrote:
>> ...
>>> If you have:
>>>
>>> extern void foo(int * restrict a, int * restrict b);
>>>
>>> and
>>>
>>> void bar(int * c) {
>>> 	foo(c, c);
>>> }
>>>
>>> then the compiler would know there is something bad going on, and could
>>> warn about it.  It would only work in a few cases - the compiler has no
>>> way of knowing if "foo(c, c + 1)" is valid or not.
>>
>> If foo() only ever accesses a[i] for even values of i, and b[i] only for
>> odd values of i, then foo(c,c) would be perfectly fine, and foo(c,c+1)
>> would not.
>>
>
> Good point.
>
> I suppose that even in the case:
>
> void bar2(int c) {
> 	foo(&c, &c);
> }
>
> then even though the only legal access through "a" and "b" is the same
> object "c", it is quite possible that foo does not access both of them.
>
> I can't think of any more possible warnings, nor any possible
> optimisations, that the compiler could make simply from knowing that the
> two arguments to "foo" are marked "restrict".

Yes, given the way "restrict" is defined, it can only have effect on 
warnings or optimizations in contexts where code that is within the 
scope of the declarations using it is visible to the compiler. For 
function parameters, that applies anywhere within the body of the 
function. For function arguments, that could only apply if the function 
was defined in the same translation unit.
Exception: insofar as the behavior of standard library functions is 
defined by the standard, a compiler effectively does know enough about 
them that it could issue warnings about possible problems caused by the 
values passed to restrict-qualified parameters.

[toc] | [prev] | [next] | [standalone]

#103946

"James R. Kuyper" <jameskuyper@verizon.net> writes:
[...]
> Yes, given the way "restrict" is defined, it can only have effect on 
> warnings or optimizations in contexts where code that is within the 
> scope of the declarations using it is visible to the compiler. For 
> function parameters, that applies anywhere within the body of the 
> function. For function arguments, that could only apply if the function 
> was defined in the same translation unit.

Except that compilers can warn about anything they like.  In particular,
given the (semantically meaningless, if I'm not mistaken) presence of
"restrict" in a function declaration, a compiler might issue warnings
based on the assumption that "restrict" is used in the same way in the
corresponding function definition.  At worst, the compiler might print
an invalid warning, which is not a conformance issue.

> Exception: insofar as the behavior of standard library functions is 
> defined by the standard, a compiler effectively does know enough about 
> them that it could issue warnings about possible problems caused by the 
> values passed to restrict-qualified parameters.

Except that the standard doesn't actually say that the "restrict"
keywords in the declarations of some standard library functions apply to
the implementations of those functions.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#103948

On 02/15/2017 12:12 PM, Keith Thompson wrote:
> "James R. Kuyper" <jameskuyper@verizon.net> writes:
> [...]
>> Yes, given the way "restrict" is defined, it can only have effect on
>> warnings or optimizations in contexts where code that is within the
>> scope of the declarations using it is visible to the compiler. For
>> function parameters, that applies anywhere within the body of the
>> function. For function arguments, that could only apply if the function
>> was defined in the same translation unit.
>
> Except that compilers can warn about anything they like.  In particular,
> given the (semantically meaningless, if I'm not mistaken) presence of
> "restrict" in a function declaration, a compiler might issue warnings
> based on the assumption that "restrict" is used in the same way in the
> corresponding function definition.  At worst, the compiler might print
> an invalid warning, which is not a conformance issue.

True - when I said "can only have effect on warnings", I meant that it's 
not possible for the compiler to be certain whether the behavior would 
be undefined without that information. Nothing prevents it from issuing 
a warning without being certain.

>> Exception: insofar as the behavior of standard library functions is
>> defined by the standard, a compiler effectively does know enough about
>> them that it could issue warnings about possible problems caused by the
>> values passed to restrict-qualified parameters.
>
> Except that the standard doesn't actually say that the "restrict"
> keywords in the declarations of some standard library functions apply to
> the implementations of those functions.

Agreed - as I myself recently pointed out recently. However, it's a 
reasonable thing to warn about, even if this particular implementation 
doesn't make corresponding optimizations to those library functions.

Of course, in most cases it would have been a good thing to warn about 
without the restrict qualifiers. Even if FILE is a complete object type 
on a particular implementation,

     read = fread(stdin, sizeof stdin, 1, stdin);

has never been a particular reasonable or safe thing to do, and

     read = fread(&errno, sizeof errno, 1, stdin);

is only a little better.

[toc] | [prev] | [next] | [standalone]

#103950

On Wednesday, February 15, 2017 at 10:36:14 AM UTC-6, James R. Kuyper wrote:
> Exception: insofar as the behavior of standard library functions is 
> defined by the standard, a compiler effectively does know enough about 
> them that it could issue warnings about possible problems caused by the 
> values passed to restrict-qualified parameters.

Insofar as the behavior of Standard Library functions is defined by the
Standard, a compiler's ability to generate such warnings would in no way be
affected by the presence or absence of "restrict" qualifiers on the arguments.

Tricky issues may arise if a compiler is paired with a separately-supplied
library which defines behaviors in some cases where the Standard does not.
If a programmer supplies a library whose implementation of memcpy is
specified to work in cases where the beginning of the source is within the
destination, it may be unclear whether the act of supplying such a
library should entitle the programmer to expect that memcpy() will work in
the indicated fashion.

A compiler could decide whether to use its own memcpy logic based upon
whether the library-supplied prototype uses "restrict", but that might not
be reliable.  A function that behaves like the above "memcpy" could be
written in strictly-conforming fashion, even with "restrict"-qualified
parameters, if it compared (source+n) for equality with (dest) before
each read, and switched to copying from (dest-(dest-src)+n) instead of
(source+n) if they were found equal.  Consequently, the presence of
"restrict" qualifiers would be immaterial as to whether the implementation
would define behavior in case of overlap.

[toc] | [prev] | [next] | [standalone]

#103957

On Wednesday, February 15, 2017 at 1:01:58 PM UTC-5, supe...@casperkitty.com wrote:
> On Wednesday, February 15, 2017 at 10:36:14 AM UTC-6, James R. Kuyper wrote:
> > Exception: insofar as the behavior of standard library functions is 
> > defined by the standard, a compiler effectively does know enough about 
> > them that it could issue warnings about possible problems caused by the 
> > values passed to restrict-qualified parameters.
> 
> Insofar as the behavior of Standard Library functions is defined by the
> Standard, a compiler's ability to generate such warnings would in no way be
> affected by the presence or absence of "restrict" qualifiers on the arguments.

With those restrict qualifiers in the definition (as opposed to the declaration) of a C standard library function, the compiler would be warning about undefined behavior. Without them, it would be warning about behavior that may be technically well-defined. I'll give an example using a user-defined function; examples using a standard library function would have to be a lot more complicated to be reasonable.

void insert_decade(
    size_t num_times,
    struct tm time_array[restrict num_times],
    struct tm *compare
){
    for(; num_times--; time_array++)
        if(time_array->tm_year >= compare->tm_year)
            time_array->tm_year += 10;
}

With the restrict qualifier, the behavior is undefined if compare points to one of the elements of time_array that gets processed. This justifies issuing a warning about any such calls, and permits an implementation to evaluate compare->tm_year only once, prior to the loop.

Without the restrict qualifier, the behavior is well-defined even if compare points to one of the elements of the array: when the while() reaches that element, then compare->tm_year will be incremented by 10, and all subsequent elements of the array will be compared with the new value of compare->tm_year, not the original value. In the unlikely event that this is exactly what you want to have happen, you might be annoyed if it decided to give you the same warning that would have been appropriate with the 'restrict' qualifier.

> Tricky issues may arise if a compiler is paired with a separately-supplied
> library which defines behaviors in some cases where the Standard does not.
> If a programmer supplies a library whose implementation of memcpy is
> specified to work in cases where the beginning of the source is within the
> destination, it may be unclear whether the act of supplying such a
> library should entitle the programmer to expect that memcpy() will work in
> the indicated fashion.

No, as far as the standard is concerned, it's quite clear that the programmer's not entitled to expect that; an implementation is always free to inline a memcpy() call using code that has been optimized in the fashion permitted by those restrict qualifiers.
If the part of the documentation for such a compiler which tells you how to link to an externally provided version of the standard library, also makes promises about how it uses that library, then it should fulfill those promises, which might prohibit such optimizations. However, that's only because the documentation says so, it's not because violating such a promise would render the combination of that compiler and that library non-conforming.

[toc] | [prev] | [next] | [standalone]

#103960

On Wednesday, February 15, 2017 at 12:55:48 PM UTC-6, jameswrote:
> With those restrict qualifiers in the definition (as opposed to the declaration) of a C standard library function, the compiler would be warning about undefined behavior. Without them, it would be warning about behavior that may be technically well-defined. I'll give an example using a user-defined function; examples using a standard library function would have to be a lot more complicated to be reasonable.

Having the qualifiers in a definition would allow a compiler *that can see
the definition* to issue warnings that would not be possible otherwise.
That doesn't imply that "restrict" within a declaration has any meaning.

> On Wednesday, February 15, 2017 at 1:01:58 PM UTC-5, supercat wrote:
> > Tricky issues may arise if a compiler is paired with a separately-supplied
> > library which defines behaviors in some cases where the Standard does not.
> > If a programmer supplies a library whose implementation of memcpy is
> > specified to work in cases where the beginning of the source is within the
> > destination, it may be unclear whether the act of supplying such a
> > library should entitle the programmer to expect that memcpy() will work in
> > the indicated fashion.
> If the part of the documentation for such a compiler which tells you how to link to an externally provided version of the standard library, also makes promises about how it uses that library, then it should fulfill those promises, which might prohibit such optimizations. However, that's only because the documentation says so, it's not because violating such a promise would render the combination of that compiler and that library non-conforming.

Indeed.  I would suggest, however, that if a compiler is designed to
facilitate use of a programmer-supplied library, it should only be regarded
as being of high quality if it *explicitly documents* cases in which it will
do something other than use the library as supplied.  In many cases where the
Standard regards various corner cases of library functions as invoking
Undefined Behavior, it does so in part to allow libraries to implement any
behavior that someone might find useful, whether or not people unfamiliar
with those implementations would expect that behavior.  The usefulness of
being able to supply a custom library implementation would be undermined if
there were no way to ensure it actually got used.

[toc] | [prev] | [next] | [standalone]

#103963

On Wednesday, February 15, 2017 at 2:42:59 PM UTC-5, supe...@casperkitty.com wrote:
> On Wednesday, February 15, 2017 at 12:55:48 PM UTC-6, jameswrote:
> > With those restrict qualifiers in the definition (as opposed to the
> > declaration) of a C standard library function, the compiler would be
> > warning about undefined behavior. Without them, it would be warning about
> > behavior that may be technically well-defined. I'll give an example using a
> > user-defined function; examples using a standard library function would
> > have to be a lot more complicated to be reasonable.
> 
> Having the qualifiers in a definition would allow a compiler *that can see
> the definition* to issue warnings that would not be possible otherwise.
> That doesn't imply that "restrict" within a declaration has any meaning.

True. That those qualifiers actually have a meaning in the standard's
declarations for standard library functions is an inference from the assumption
that the committee was not stupid enough to insert meaningless qualifiers - the
standard itself says nothing to confirm that inference.

My guess as to the intended meaning is that implementation are permitted, but
not required, to use implementations for standard library functions that are
optimized in the fashion that would be permitted for user code if they were
implementable in C, and were in fact implemented using those qualifiers in the
function prototype at the start of the function definition. Those optimization
are permitted even if the function isn't actually implemented in C, and even if
it would have been impossible to implement it completely in strictly conforming
C code. It would be correspondingly a bad idea to call those functions with
arguments that would give a function undefined behavior if it were implemented
in that way.

...
> > If the part of the documentation for such a compiler which tells you how to
> > link to an externally provided version of the standard library, also makes
> > promises about how it uses that library, then it should fulfill those
> > promises, which might prohibit such optimizations. However, that's only
> > because the documentation says so, it's not because violating such a
> > promise would render the combination of that compiler and that library
> > non-conforming.
> 
> Indeed.  I would suggest, however, that if a compiler is designed to
> facilitate use of a programmer-supplied library, it should only be regarded

I know of no compilers which are intended to facilitate use of arbitrary
programmer supplied implementations of the C standard library. The only ones I
know of are only intended to work with standard library implementations that
are, in themselves, fully conform to the standard's requirements on that
library. They might or might not work in any reasonable fashion with a library
that takes any liberties with the standard's requirements.

> as being of high quality if it *explicitly documents* cases in which it will
> do something other than use the library as supplied.

I disagree. If it documents only that it will work with fully conforming
implementations of the C standard library, to produce behavior that fully
conforms to the C standard, I would consider it to have sufficiently high
quality so long as it fulfilled those promises, even if it produced a different
form of unspecified behavior than the library would have produced, in any
circumstance where the behavior is not implementation-defined. That includes
undefined behavior as a special case.

In particular, in those cases where the behavior is implementation-defined,
fully conforming to the standard requires that the documentation correctly
define what the behavior will be - whether it correctly defines behavior that
is independent of the chosen library's behavior, or it correctly defines the
behavior in terms of the chosen library's behavior - all that matters is that
whatever definition it provides correctly matches the behavior that it
produces. 

> ... In many cases where the
> Standard regards various corner cases of library functions as invoking
> Undefined Behavior, it does so in part to allow libraries to implement any
> behavior that someone might find useful, whether or not people unfamiliar
> with those implementations would expect that behavior.  The usefulness of
> being able to supply a custom library implementation would be undermined if
> there were no way to ensure it actually got used.

I don't think supporting arbitrary "custom library implementations" is the
intended purpose of such compilers, though you might be able to get away with
it. The purpose was to avoid having to provide a library implementation of
their own.

[toc] | [prev] | [next] | [standalone]

#103973

On Wednesday, February 15, 2017 at 2:28:17 PM UTC-6, james...@verizon.net wrote:
> True. That those qualifiers actually have a meaning in the standard's
> declarations for standard library functions is an inference from the assumption
> that the committee was not stupid enough to insert meaningless qualifiers - the
> standard itself says nothing to confirm that inference.

The Standard's declarations include parameter names which would offer no
benefit to a compiler processing the declarations, but do offer benefit
to humans reading the Standard.  I see no reason not to view "restrict"
qualifiers likewise.

> My guess as to the intended meaning is that implementation are permitted, but
> not required, to use implementations for standard library functions that are
> optimized in the fashion that would be permitted for user code if they were
> implementable in C, and were in fact implemented using those qualifiers in the
> function prototype at the start of the function definition. Those optimization
> are permitted even if the function isn't actually implemented in C, and even if
> it would have been impossible to implement it completely in strictly conforming
> C code. It would be correspondingly a bad idea to call those functions with
> arguments that would give a function undefined behavior if it were implemented
> in that way.

It would be possible to implement a strictly-conforming memmove even if
the parameters had "restrict" qualifiers.  It actually wouldn't be much
harder than implementing one with parameters that didn't have such
qualifiers.  Strictly-conforming code can check if two character pointers
identify overlapping regions of size N by checking if p+i==q or q+i==p
for any value if i in the range 0..N-1, and if two pointers are found to
overlap it will be safe to copy data from (dest+offset) to dest without
having to access anything through the source pointer.

> I know of no compilers which are intended to facilitate use of arbitrary
> programmer supplied implementations of the C standard library. The only ones I
> know of are only intended to work with standard library implementations that
> are, in themselves, fully conform to the standard's requirements on that
> library. They might or might not work in any reasonable fashion with a library
> that takes any liberties with the standard's requirements.

The fact that a library would guarantee behaviors beyond what the Standard
would mandate does not imply that it is non-conforming.

> > as being of high quality if it *explicitly documents* cases in which it will
> > do something other than use the library as supplied.
> 
> I disagree. If it documents only that it will work with fully conforming
> implementations of the C standard library, to produce behavior that fully
> conforms to the C standard, I would consider it to have sufficiently high
> quality so long as it fulfilled those promises, even if it produced a different
> form of unspecified behavior than the library would have produced, in any
> circumstance where the behavior is not implementation-defined. That includes
> undefined behavior as a special case.

Having compilers document cases in which what appears to be a standard
function call may be treated in some other fashion would seem desirable,
and not unreasonably burdensome.  I would certainly regard such
documentation as an indication of quality even if you would not.  Among
other things, if a header file for the library includes inline functions
that call other library functions, those functions--as part of a standard
library implementations--should be entitled to rely upon library
implementation details beyond those required by the Standard, but that
might not work if the compiler substitutes its own alternatives.  For
example, if stdlib.h were to contain:

    inline size_t __alloc_size(void *p)
    {
      return ((size_t*)p)[-1];
    }

because the implementer knows that its malloc() and related functions store
the size of each allocation in the word immediately before it, should a
quality compiler given code like:

    size_t test(size_t n)
    {
      void *p = malloc(n);
      size_t result = __alloc_size(p);
      free(p);
      return result;
    }

decide that such a function is unreachable since it accesses memory outside
an allocated region, should it replace the malloc and free with a stack
application, oblivious to the out-of-bounds access, or should it treat the
the seemingly-out-of-bounds access as a sign that it must perform literal
calls to malloc/free?

Any of those behaviors may be justifiable, but I would expect that a quality
compiler which would attempt to optimize out malloc/free calls should
document any cases where that might affect program behavior.

> > ... In many cases where the
> > Standard regards various corner cases of library functions as invoking
> > Undefined Behavior, it does so in part to allow libraries to implement any
> > behavior that someone might find useful, whether or not people unfamiliar
> > with those implementations would expect that behavior.  The usefulness of
> > being able to supply a custom library implementation would be undermined if
> > there were no way to ensure it actually got used.
> 
> I don't think supporting arbitrary "custom library implementations" is the
> intended purpose of such compilers, though you might be able to get away with
> it. The purpose was to avoid having to provide a library implementation of
> their own.

In the world of embedded and systems programming, having precise control
over such things is often important.  Having a freestanding implementation
which could behave as a hosted implementation by adding a library would be
useful, but such a library would need the ability to reliably use systems-
programming constructs.

[toc] | [prev] | [next] | [standalone]

#103887

supercat@casperkitty.com writes:
> On Tuesday, February 14, 2017 at 6:29:50 AM UTC-6, David Brown wrote:
>> It does not have "restrict".  There is nothing to stop an implementation
>> /adding/ information - but it should not skip things.
>
> Does "restrict" serve any more purpose in a prototype than identifier names?

Strictly speaking, no.  But it's reasonable to assume that any restrict
keywords in a function declaration match those in the corresponding
function definition, and for a compiler to issue warnings based on that
assumption.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#103886

BartC <bc@freeuk.com> writes:
> On 14/02/2017 08:28, David Brown wrote:
[...]
>> Standard library code is part of the implementation.  Even if it is
>> developed separately from the compiler, it is still in close cooperation
>> with the compiler.
>
> "The" compiler? I thought such libraries were completely independent 
> from any one compiler and were all interchangable?

What gave you that idea?

> Or you finally admitting that perhaps the MingW library /is/ really 
> designed to work with gcc?

"finally admitting"?

Of course it is.  MinGW is an implementation that include gcc as its
compiler.  The library component of MinGW is, as far as I know, intended
to work with gcc, and only with gcc.  Has anyone claimed otherwise?

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#103898

On 14/02/17 16:51, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 14/02/2017 08:28, David Brown wrote:
> [...]
>>> Standard library code is part of the implementation.  Even if it is
>>> developed separately from the compiler, it is still in close cooperation
>>> with the compiler.
>>
>> "The" compiler? I thought such libraries were completely independent
>> from any one compiler and were all interchangable?
>
> What gave you that idea?
>
>> Or you finally admitting that perhaps the MingW library /is/ really
>> designed to work with gcc?
>
> "finally admitting"?
>
> Of course it is.  MinGW is an implementation that include gcc as its
> compiler.  The library component of MinGW is, as far as I know, intended
> to work with gcc, and only with gcc.  Has anyone claimed otherwise?

No, of course they haven't. YHBT.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web