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

Groups > comp.lang.c > #103512

Re: Using fread function

Show all headers | View raw

jameskuyper@verizon.net writes:

> On Wednesday, February 1, 2017 at 4:59:24 PM UTC-5, Tim Rentsch wrote:
>> "James R.  Kuyper" <jameskuyper@verizon.net> writes:
>
> ...
>
>>> Since C99, according to 7.21,.8.1p1, the correct prototype is
>>>
>>>     size_t fread(void * restrict ptr,
>>>          size_t size, size_t nmemb,
>>>          FILE * restrict stream);
>>>
>>> The significance of this change from C90 is that its now explicitly
>>> undefined behavior if there's any overlap between the FILE object
>>> pointed at by stream, and the first size*nmemb bytes of the memory
>>> pointed at by ptr.  [...]
>>
>> Is it?  I agree that the intention in such cases is that they be
>> undefined behavior, but AFAIK there is no explicit statement in
>> the Standard that makes such a rule.  Based just on the function
>> prototype, we can't conclude anything about how the function is
>> defined (ie, in this respect), since the two 'restrict's do not
>> participate in type compatibility.  Is there some passage in
>> the Standard that makes this inference iron-clad, or is it just
>> a guess at what was meant?  If there is such a passage, what is
>> it (or are they)?
>
> Sorry for taking so long to reply.  I recognized the issue you raised
> as soon as I read your message, but I wanted to check every relevant
> detail before responding, and I didn't have time to do so before
> today.

No worries.  I appreciate the double check.

> Qualifiers that are applied directly to the parameters in a function
> prototype that is not a function definition are pretty much
> completely irrelevant (this is not true of qualifiers that apply to
> the pointed-at type of a pointer parameter, rather than to the
> parameter itself).  Arguments to a prototyped function are converted
> to the unqualified version of the corresponding parameter's type
> (6.5.2.2p2).  Qualifiers on parameters of function declarations are
> ignored when determining whether or not the corresponding types are
> compatible (6.7.6.3p15).  The requirement that "All declarations that
> refer to the same ... function shall have compatible type;
> otherwise, the behavior is undefined."  (6.2.7p2) does not,
> therefore, require that parameter types in different declarations be
> identically qualified.
> In particular, this means that the parameter types in a function
> definition's declaration need not have the same qualifiers that they
> had in any other declaration of that same function.
> The consequences of a parameter's qualifier apply only to lvalue
> expressions (6.7.3p4) involving the qualified identifier, which can
> occur only inside the definition of the function that the parameter
> is part of.  Therefore, the "restrict" qualifiers that the standard
> specifies for standard library functions in section 7 would
> technically be completely meaningless, even if the standard did
> require that C standard library functions be implemented in C (which
> it does not).
>
> I don't think those qualifiers are intended to be meaningless.  I
> think that they were intended to convey permission for implementors
> to perform the same optimizations within the implementation of
> standard library routines that would be permitted if they were
> implemented in C using those prototypes in the function definition.
> I recommend that all developers assume that this is the case, and
> therefore avoid code that would have would have undefined behavior if
> it were the case.  However, I concede that I cannot find any wording
> in the standard that says anything of the kind.
>
> Section 6.7.3.1 of the Rationale mentions that
>
> "The restrict qualifier can be used to express the restriction on
> overlap in a new prototype that is compatible with the original
> version:"
>      void *memcpy(void * restrict s1, const void * restrict s2,
>      size_t n);"
>
> The Rationale is not normative, but gives insight into the committee's intent.

Seems like rather a long way of saying, "I think you're right.
It seems clear that the intention is that there be undefined
behavior in such cases, but AFAICT the Standard never actually
comes right out and says so (or gives any explicit statement to
that effect)."

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Using fread function janus <emekamicro@gmail.com> - 2017-01-29 10:07 -0800
  Re: Using fread function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-29 14:31 -0500
    Re: Using fread function supercat@casperkitty.com - 2017-01-30 08:03 -0800
    Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 13:59 -0800
      Re: Using fread function jameskuyper@verizon.net - 2017-02-05 11:40 -0800
        Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 22:04 -0800
          Re: Using fread function jameskuyper@verizon.net - 2017-02-09 05:39 -0800
            Re: Using fread function supercat@casperkitty.com - 2017-02-09 07:47 -0800
              Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-02-09 09:19 -0800
                Re: Using fread function supercat@casperkitty.com - 2017-02-09 09:55 -0800
                Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-02-09 12:10 -0800
                Re: Using fread function supercat@casperkitty.com - 2017-02-09 13:01 -0800
              Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-12 09:36 -0800
                Re: Using fread function supercat@casperkitty.com - 2017-02-12 10:52 -0800
                Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 21:19 -0800
                Re: Using fread function supercat@casperkitty.com - 2017-02-20 09:35 -0800
                Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-02-20 09:52 -0800
                Re: Using fread function supercat@casperkitty.com - 2017-02-20 11:15 -0800
                Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-02-20 11:45 -0800
                Re: Using fread function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-20 15:38 -0500
                Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 12:12 -0800
                Re: Using fread function jameskuyper@verizon.net - 2017-02-24 10:37 -0800
                Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 05:04 -0800
                Re: Using fread function supercat@casperkitty.com - 2017-02-23 07:58 -0800
                Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-25 11:48 -0800
                Re: Using fread function jameskuyper@verizon.net - 2017-02-25 13:44 -0800
                Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-17 13:12 -0700
                Re: Using fread function supercat@casperkitty.com - 2017-04-17 13:50 -0700
            Re: Using fread function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-12 09:31 -0800
  Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-01-29 13:14 -0800
  Re: Using fread function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-30 08:18 -0800
    Re: Using fread function supercat@casperkitty.com - 2017-01-30 08:44 -0800
    Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-01-30 11:58 -0800
      Re: Using fread function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-30 13:05 -0800
        Re: Using fread function supercat@casperkitty.com - 2017-01-30 13:39 -0800
        Re: Using fread function Keith Thompson <kst-u@mib.org> - 2017-01-30 13:57 -0800

csiph-web