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

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

isspace() executes without ctype header?

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

Contents

  isspace() executes without ctype header? DFS <nospam@dfs.com> - 2017-06-13 21:13 -0400
    Re: isspace() executes without ctype header? Ian Collins <ian-news@hotmail.com> - 2017-06-14 13:20 +1200
      Re: isspace() executes without ctype header? DFS <nospam@dfs.com> - 2017-06-13 21:33 -0400
        Re: isspace() executes without ctype header? Ian Collins <ian-news@hotmail.com> - 2017-06-14 13:35 +1200
          Re: isspace() executes without ctype header? DFS <nospam@dfs.com> - 2017-06-13 22:31 -0400
            Re: isspace() executes without ctype header? Ian Collins <ian-news@hotmail.com> - 2017-06-14 14:40 +1200
    Re: isspace() executes without ctype header? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-06-13 21:49 -0400
    Re: isspace() executes without ctype header? Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-13 19:20 -0700
      Re: isspace() executes without ctype header? DFS <nospam@dfs.com> - 2017-06-13 23:04 -0400
        Re: isspace() executes without ctype header? asetofsymbols@gmail.com - 2017-06-13 23:07 -0700
        Re: isspace() executes without ctype header? Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-14 08:26 -0700
          Re: isspace() executes without ctype header? bartc <bc@freeuk.com> - 2017-06-14 17:29 +0100
            Re: isspace() executes without ctype header? Keith Thompson <kst-u@mib.org> - 2017-06-14 09:46 -0700
              Re: isspace() executes without ctype header? bartc <bc@freeuk.com> - 2017-06-14 17:54 +0100
                Re: isspace() executes without ctype header? Keith Thompson <kst-u@mib.org> - 2017-06-14 10:17 -0700
                Re: isspace() executes without ctype header? supercat@casperkitty.com - 2017-06-14 10:48 -0700
                  Re: isspace() executes without ctype header? Keith Thompson <kst-u@mib.org> - 2017-06-14 12:03 -0700
                    Re: isspace() executes without ctype header? supercat@casperkitty.com - 2017-06-14 12:48 -0700
                      Re: isspace() executes without ctype header? Keith Thompson <kst-u@mib.org> - 2017-06-14 13:06 -0700
              Re: isspace() executes without ctype header? Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-16 23:14 -0700
    Re: isspace() executes without ctype header? bartc <bc@freeuk.com> - 2017-06-14 11:18 +0100
      Re: isspace() executes without ctype header? Keith Thompson <kst-u@mib.org> - 2017-06-14 09:35 -0700
        Re: isspace() executes without ctype header? bartc <bc@freeuk.com> - 2017-06-14 17:47 +0100
          Re: isspace() executes without ctype header? supercat@casperkitty.com - 2017-06-14 10:19 -0700
            Re: isspace() executes without ctype header? Keith Thompson <kst-u@mib.org> - 2017-06-14 10:29 -0700
          Re: isspace() executes without ctype header? Keith Thompson <kst-u@mib.org> - 2017-06-14 10:21 -0700
            Re: isspace() executes without ctype header? bartc <bc@freeuk.com> - 2017-06-14 19:12 +0100
              Re: isspace() executes without ctype header? Keith Thompson <kst-u@mib.org> - 2017-06-14 12:12 -0700
              Re: isspace() executes without ctype header? joel.rees@gmail.com - 2017-06-16 17:56 -0700
                Re: isspace() executes without ctype header? supercat@casperkitty.com - 2017-06-17 10:20 -0700
                  Re: isspace() executes without ctype header? Robert Wessel <robertwessel2@yahoo.com> - 2017-06-18 00:25 -0500
                    Re: isspace() executes without ctype header? supercat@casperkitty.com - 2017-06-19 09:01 -0700
                      Re: isspace() executes without ctype header? Robert Wessel <robertwessel2@yahoo.com> - 2017-06-19 21:59 -0500

Page 1 of 2  [1] 2  Next page →

#112147 — isspace() executes without ctype header?

Seems strange, but the code compiles (Tiny C on Windows) and runs just 
fine with only stdio.h and stdlib.h includes.

Online resources say ctype.h is the required header (which I didn't know 
obviously).

I compiled the program with Pelles and got warnings:

Undeclared function 'isspace' (did you mean 'vsscanf'?); assuming 
'extern' returning 'int'.


Why is it working without ctype.h?

[toc] | [next] | [standalone]

#112148

On 06/14/17 01:13 PM, DFS wrote:
> Seems strange, but the code compiles (Tiny C on Windows) and runs just
> fine with only stdio.h and stdlib.h includes.
>
> Online resources say ctype.h is the required header (which I didn't know
> obviously).
>
> I compiled the program with Pelles and got warnings:
>
> Undeclared function 'isspace' (did you mean 'vsscanf'?); assuming
> 'extern' returning 'int'.
>
>
> Why is it working without ctype.h?

Do both compilers use system headers. or do they provide their own?

-- 
Ian

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

#112149

On 6/13/2017 9:20 PM, Ian Collins wrote:
> On 06/14/17 01:13 PM, DFS wrote:
>> Seems strange, but the code compiles (Tiny C on Windows) and runs just
>> fine with only stdio.h and stdlib.h includes.
>>
>> Online resources say ctype.h is the required header (which I didn't know
>> obviously).
>>
>> I compiled the program with Pelles and got warnings:
>>
>> Undeclared function 'isspace' (did you mean 'vsscanf'?); assuming
>> 'extern' returning 'int'.
>>
>>
>> Why is it working without ctype.h?
> 
> Do both compilers use system headers. or do they provide their own?

I already uninstalled Pelles, but it looks like tcc provides their own. 
The stdio.h and stdlib.h files in tcc/include both say 'This file is 
part of the w64 mingw-runtime package.'

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

#112150

On 06/14/17 01:33 PM, DFS wrote:
> On 6/13/2017 9:20 PM, Ian Collins wrote:
>> On 06/14/17 01:13 PM, DFS wrote:
>>> Seems strange, but the code compiles (Tiny C on Windows) and runs just
>>> fine with only stdio.h and stdlib.h includes.
>>>
>>> Online resources say ctype.h is the required header (which I didn't know
>>> obviously).
>>>
>>> I compiled the program with Pelles and got warnings:
>>>
>>> Undeclared function 'isspace' (did you mean 'vsscanf'?); assuming
>>> 'extern' returning 'int'.
>>>
>>>
>>> Why is it working without ctype.h?
>>
>> Do both compilers use system headers. or do they provide their own?
>
> I already uninstalled Pelles, but it looks like tcc provides their own.
> The stdio.h and stdlib.h files in tcc/include both say 'This file is
> part of the w64 mingw-runtime package.'

So either of the two headers you included probably include <ctype.h>.

-- 
Ian

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

#112154

On 6/13/2017 9:35 PM, Ian Collins wrote:
> On 06/14/17 01:33 PM, DFS wrote:
>> On 6/13/2017 9:20 PM, Ian Collins wrote:
>>> On 06/14/17 01:13 PM, DFS wrote:
>>>> Seems strange, but the code compiles (Tiny C on Windows) and runs just
>>>> fine with only stdio.h and stdlib.h includes.
>>>>
>>>> Online resources say ctype.h is the required header (which I didn't 
>>>> know
>>>> obviously).
>>>>
>>>> I compiled the program with Pelles and got warnings:
>>>>
>>>> Undeclared function 'isspace' (did you mean 'vsscanf'?); assuming
>>>> 'extern' returning 'int'.
>>>>
>>>>
>>>> Why is it working without ctype.h?
>>>
>>> Do both compilers use system headers. or do they provide their own?
>>
>> I already uninstalled Pelles, but it looks like tcc provides their own.
>> The stdio.h and stdlib.h files in tcc/include both say 'This file is
>> part of the w64 mingw-runtime package.'
> 
> So either of the two headers you included probably include <ctype.h>.


I checked.  Neither of them reference ctype.h in any way.

Both reference _mingw.h, and the closest thing in _mingw.h is:

typedef unsigned short wctype_t;
#define _WCTYPE_T_DEFINED

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

#112155

On 06/14/17 02:31 PM, DFS wrote:
> On 6/13/2017 9:35 PM, Ian Collins wrote:
>> On 06/14/17 01:33 PM, DFS wrote:
>>> On 6/13/2017 9:20 PM, Ian Collins wrote:
>>>> On 06/14/17 01:13 PM, DFS wrote:
>>>>> Seems strange, but the code compiles (Tiny C on Windows) and runs just
>>>>> fine with only stdio.h and stdlib.h includes.
>>>>>
>>>>> Online resources say ctype.h is the required header (which I didn't
>>>>> know
>>>>> obviously).
>>>>>
>>>>> I compiled the program with Pelles and got warnings:
>>>>>
>>>>> Undeclared function 'isspace' (did you mean 'vsscanf'?); assuming
>>>>> 'extern' returning 'int'.
>>>>>
>>>>>
>>>>> Why is it working without ctype.h?
>>>>
>>>> Do both compilers use system headers. or do they provide their own?
>>>
>>> I already uninstalled Pelles, but it looks like tcc provides their own.
>>> The stdio.h and stdlib.h files in tcc/include both say 'This file is
>>> part of the w64 mingw-runtime package.'
>>
>> So either of the two headers you included probably include <ctype.h>.
>
>
> I checked.  Neither of them reference ctype.h in any way.
>
> Both reference _mingw.h, and the closest thing in _mingw.h is:
>
> typedef unsigned short wctype_t;
> #define _WCTYPE_T_DEFINED

The other responses are a more likely answer (implicit int).

-- 
Ian

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

#112151

DFS wrote:

> Seems strange, but the code compiles (Tiny C on Windows) and runs just
> fine with only stdio.h and stdlib.h includes.
> 
> Online resources say ctype.h is the required header (which I didn't know
> obviously).
> 
> I compiled the program with Pelles and got warnings:
> 
> Undeclared function 'isspace' (did you mean 'vsscanf'?); assuming
> 'extern' returning 'int'.
> 
> 
> Why is it working without ctype.h?

Because your compiler guessed correctly about the parameter types that the 
function takes, and the type of the value the function returns.

It likely took your word for the parameter types, though (based on how you 
invoked the function).

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#112152

DFS <nospam@dfs.com> writes:

> Seems strange, but the code compiles (Tiny C on Windows) and runs just
> fine with only stdio.h and stdlib.h includes.

Do you mean it compiles without giving any diagnostics?

> Online resources say ctype.h is the required header (which I didn't
> know obviously).
>
> I compiled the program with Pelles and got warnings:
>
> Undeclared function 'isspace' (did you mean 'vsscanf'?); assuming
> extern' returning 'int'.
>
>
> Why is it working without ctype.h?

If Tiny C defaults to C89/C90, then a call to isspace() without
a prior declaration will implicitly declare the function, with
a return type of int.  The linux tcc I have does not do that,
but I expect it is a different version.

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

#112156

On 6/13/2017 10:20 PM, Tim Rentsch wrote:
> DFS <nospam@dfs.com> writes:
> 
>> Seems strange, but the code compiles (Tiny C on Windows) and runs just
>> fine with only stdio.h and stdlib.h includes.
> 
> Do you mean it compiles without giving any diagnostics?

Yes.  No warnings or errors at all.



>> Online resources say ctype.h is the required header (which I didn't
>> know obviously).
>>
>> I compiled the program with Pelles and got warnings:
>>
>> Undeclared function 'isspace' (did you mean 'vsscanf'?); assuming
>> extern' returning 'int'.
>>
>>
>> Why is it working without ctype.h?
> 
> If Tiny C defaults to C89/C90, 

The website implies it defaults to C99.

One of the changelog entries of an earlier version says:

Define __STDC_VERSION__=199901L (477)


> then a call to isspace() without
> a prior declaration will implicitly declare the function, with
> a return type of int.  The linux tcc I have does not do that,
> but I expect it is a different version.


tcc version 0.9.26 (x86-64 Win64)


Do you get a function not declared warning?

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

#112166

with warning the compiler i use
can compile/link all with function on Library of C

but there are problems with functions that use "double"
perhaps because if the function prototype is not seen from compiler

all types are seen as int...

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

#112188

DFS <nospam@dfs.com> writes:

> On 6/13/2017 10:20 PM, Tim Rentsch wrote:
>
>> DFS <nospam@dfs.com> writes:
>>
>>> Seems strange, but the code compiles (Tiny C on Windows) and runs just
>>> fine with only stdio.h and stdlib.h includes.
>>
>> Do you mean it compiles without giving any diagnostics?
>
> Yes.  No warnings or errors at all.
>
>>> Online resources say ctype.h is the required header (which I didn't
>>> know obviously).
>>>
>>> I compiled the program with Pelles and got warnings:
>>>
>>> Undeclared function 'isspace' (did you mean 'vsscanf'?); assuming
>>> extern' returning 'int'.
>>>
>>>
>>> Why is it working without ctype.h?
>>
>> If Tiny C defaults to C89/C90,
>
> The website implies it defaults to C99.
>
> One of the changelog entries of an earlier version says:
>
> Define __STDC_VERSION__=199901L (477)
>
>
>> then a call to isspace() without
>> a prior declaration will implicitly declare the function, with
>> a return type of int.  The linux tcc I have does not do that,
>> but I expect it is a different version.
>
> tcc version 0.9.26 (x86-64 Win64)

Huh.  I get the same version number (0.9.26 (x86-64 Linux)).

> Do you get a function not declared warning?

Yes, the message I get is

    isspace-check.c:6: warning: implicit declaration of function 'isspace'

Sorry not to be of more help.  Presumably isspace() is declared
in one of the two headers you #include'd.  You might try this
to diagnose it:

    #include <stdio.h>
    #include <stdlib.h>

    #undef isspace
    static int isspace( int x ){ return 0; }

If compiling that gives you an error, that's a strong indication
that isspace() is declared in one of the headers.

Oh, come to think of it, you might also try just #undef isspace
after the two #include's in your original program, in case
there is an isspace() macro that expands to call some internal
function.  Either way I believe the behavior you are seeing
is non-conforming, but it would be reassuring to discover
the mechanism by which the non-conforming behavior is induced.

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

#112197

On 14/06/2017 16:26, Tim Rentsch wrote:
> DFS <nospam@dfs.com> writes:

>> Do you get a function not declared warning?
> 
> Yes, the message I get is
> 
>      isspace-check.c:6: warning: implicit declaration of function 'isspace'

> Oh, come to think of it, you might also try just #undef isspace
> after the two #include's in your original program, in case
> there is an isspace() macro that expands to call some internal
> function.  Either way I believe the behavior you are seeing
> is non-conforming, but it would be reassuring to discover
> the mechanism by which the non-conforming behavior is induced.


I tried compiling this:

int main(void){
   isspace(0);
}

I get no messages at all from either of the two tccs I have on Windows 
(0.9.26, 32- and 64-buit versions).

Same with isspace(0,0). Same with isspace("abc"). So it's not just 
assuming implicit int.

Putting in a declaration like this however:

   int isspace(int);

generates an error and warning respectively on those last two calls.

-- 
bartc

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

#112199

bartc <bc@freeuk.com> writes:
[...]
> I tried compiling this:
>
> int main(void){
>    isspace(0);
> }
>
> I get no messages at all from either of the two tccs I have on Windows 
> (0.9.26, 32- and 64-buit versions).

That behavior is consistent with a conforming C90 compiler.

> Same with isspace(0,0). Same with isspace("abc"). So it's not just 
> assuming implicit int.

Yes it is.  The C90 implicit int rule assumes that an undeclared
function takes arguments of the (promoted) types in the call,
and returns int.  (If that assumption is inconsistent with the
actual definition, as it is for isspace(0,0) and isspace("abc"),
the behavior is undefined.)

> Putting in a declaration like this however:
>
>    int isspace(int);
>
> generates an error and warning respectively on those last two calls.

Again, that's consistent with a conforming C90 compiler.  (Adding
"#include <ctype.h>" should have the same effect.)

On my system (Ubuntu 16.10):

    % cat c.c
    int main(void){
    isspace(0);
    }
    % tcc -c c.c
    c.c:1: warning: implicit declaration of function 'isspace'
    % tcc -v
    tcc version 0.9.26 (x86-64 Linux)
    %

It's a little surprising that tcc 0.9.26 complains about the implicit
declaration on Linux but not on Windows.

-- 
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]

#112203

On 14/06/2017 17:46, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> [...]
>> I tried compiling this:
>>
>> int main(void){
>>     isspace(0);
>> }
>>
>> I get no messages at all from either of the two tccs I have on Windows
>> (0.9.26, 32- and 64-buit versions).
> 
> That behavior is consistent with a conforming C90 compiler.
> 
>> Same with isspace(0,0). Same with isspace("abc"). So it's not just
>> assuming implicit int.
> 
> Yes it is.  The C90 implicit int rule assumes that an undeclared
> function takes arguments of the (promoted) types in the call,
> and returns int.  (If that assumption is inconsistent with the
> actual definition, as it is for isspace(0,0) and isspace("abc"),
> the behavior is undefined.)

In the second example, the argument type is char*, the assumed parameter 
type is int. Why doesn't it complain about pointer to int conversion? It 
will do so when the int parameter is properly declared.

-- 
Bartc

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

#112206

bartc <bc@freeuk.com> writes:
> On 14/06/2017 17:46, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> [...]
>>> I tried compiling this:
>>>
>>> int main(void){
>>>     isspace(0);
>>> }
>>>
>>> I get no messages at all from either of the two tccs I have on Windows
>>> (0.9.26, 32- and 64-buit versions).
>> 
>> That behavior is consistent with a conforming C90 compiler.
>> 
>>> Same with isspace(0,0). Same with isspace("abc"). So it's not just
>>> assuming implicit int.
>> 
>> Yes it is.  The C90 implicit int rule assumes that an undeclared
>> function takes arguments of the (promoted) types in the call,
>> and returns int.  (If that assumption is inconsistent with the
>> actual definition, as it is for isspace(0,0) and isspace("abc"),
>> the behavior is undefined.)
>
> In the second example, the argument type is char*, the assumed parameter 
> type is int. Why doesn't it complain about pointer to int conversion? It 
> will do so when the int parameter is properly declared.

No, there is no assumption that the parameter type is int.

C90 6.3.2.2:

    If the expression that precedes the parenthesized argument list
    in a function call consists solely of an identifier, and if
    no declaration is visible for this identifier, the identifier
    is implicitly declared exactly as if, in the innermost block
    containing the function call, the declaration                                                                                            
        extern int identifier () ;

    appeared.

    If the expression that denotes the called function has a type
    that does not include a prototype, the integral promotions
    are performed on each argument and arguments that have type
    float are promoted to double. These are called the *default
    argument promotions*.  If the number of arguments does not agree
    with the number of parameters, the behavior is undefined. If
    the function is defined with a type that does not include a
    prototype, and the types of the arguments after promotion are
    not compatible with those of the parameters after promotion,
    the behavior is undefined.

-- 
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]

#112210

On Wednesday, June 14, 2017 at 11:54:20 AM UTC-5, Bart wrote:
> In the second example, the argument type is char*, the assumed parameter 
> type is int. Why doesn't it complain about pointer to int conversion? It 
> will do so when the int parameter is properly declared.

The assumed return type is "int".  The assumed parameter type is whatever
would match an argument that has been subjected to default promotions.
When C was first designed, there were three categories of arguments, and
thus three types of parameters:

  A pointer of some kind (pass as the bulkiest pointer type)
  A floating-point number of some kind (pass as the bulkiest FP type)
  An integer of some kind (pass as the bulkiest integer type)

The principle that the type used to pass an argument to a parameter of
unknown type should depend merely on the category, rather than its exact
type, is a good one, but was not retained when C added more types.  It
works fine for the C74 types, though.

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

#112214

supercat@casperkitty.com writes:
> On Wednesday, June 14, 2017 at 11:54:20 AM UTC-5, Bart wrote:
>> In the second example, the argument type is char*, the assumed parameter 
>> type is int. Why doesn't it complain about pointer to int conversion? It 
>> will do so when the int parameter is properly declared.
>
> The assumed return type is "int".  The assumed parameter type is whatever
> would match an argument that has been subjected to default promotions.
> When C was first designed, there were three categories of arguments, and
> thus three types of parameters:
>
>   A pointer of some kind (pass as the bulkiest pointer type)
>   A floating-point number of some kind (pass as the bulkiest FP type)
>   An integer of some kind (pass as the bulkiest integer type)

I don't recall there being any concept of the "bulkiest pointer
type".  Pointer types are distinct, and an int* argument would
be passed as int* even if char* is bigger.  (Note that there was
no void*.)  If you passed an int* argument to a function expecting a
char*, I think you'd have what C currently calls undefined behavior,
particularly if they have different representations.

Both cman74.pdf and cman.pdf (from 1975, I think) says that char
arguments are promoted to int, and float arguments to double.
(char, int, float, and double were the only numeric types.)
No other conversions are specified.


> The principle that the type used to pass an argument to a parameter of
> unknown type should depend merely on the category, rather than its exact
> type, is a good one, but was not retained when C added more types.  It
> works fine for the C74 types, though.

Yes, when long and long double were added, the unstated "bulkiest type"
rule was not extended to include them.  But I'm not convinced there ever
was such a rule, even implicitly, since it never applied to pointers.
(Or, later, to structs and unions.)

-- 
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]

#112218

On Wednesday, June 14, 2017 at 2:03:52 PM UTC-5, Keith Thompson wrote:
> Both cman74.pdf and cman.pdf (from 1975, I think) says that char
> arguments are promoted to int, and float arguments to double.
> (char, int, float, and double were the only numeric types.)
> No other conversions are specified.

The layout of passed arguments was effectively documented by the sample
printf function, and there were no aliasing rules.  I will grant that it
is unclear whether implementations would have been expected to ensure that
a memcpy-style function could be invoked without requiring a caller-side
cast, but I don't recall anything in that manual that would suggest that
such a cast would be needed.

> Yes, when long and long double were added, the unstated "bulkiest type"
> rule was not extended to include them.  But I'm not convinced there ever
> was such a rule, even implicitly, since it never applied to pointers.
> (Or, later, to structs and unions.)

A fundamental difference between aggregate types and scalar types is that
scalar types are subject to implicit promotions in various cases, while
aggregate types are not.  If 'x' is of type "float" and equals 100000.0f,
there are several sensible ways a language could process "foo(f-99999.9)".
Allowing a function to receive the result of (f-99999.9) the same way
as (f), without having to unduly limit the accuracy of the latter
calculation, would seem better than having to either (1) use functions that
process the values differently, (2) add an explicit cast to one of the
invocations, or (3) round off the decimal literal to 99999+(115/128),
thus yielding a value of -0.1015625.

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

#112220

supercat@casperkitty.com writes:
> On Wednesday, June 14, 2017 at 2:03:52 PM UTC-5, Keith Thompson wrote:
>> Both cman74.pdf and cman.pdf (from 1975, I think) says that char
>> arguments are promoted to int, and float arguments to double.
>> (char, int, float, and double were the only numeric types.)
>> No other conversions are specified.
>
> The layout of passed arguments was effectively documented by the sample
> printf function, and there were no aliasing rules.  I will grant that it
> is unclear whether implementations would have been expected to ensure that
> a memcpy-style function could be invoked without requiring a caller-side
> cast, but I don't recall anything in that manual that would suggest that
> such a cast would be needed.

The sample printf implementation in cman.pdf accepts arguments of types
int, double, and char* (the latter points to a string for "%s").  The
code that handles the arguments increments a pointer to int for int
arguments, a pointer to double for double arguments, and a pointer to
char* for char* arguments.  It certainly assumes that arguments are
allocated sequentially and in order, but I see no assumptions about the
representations of different pointer types.  And it clearly says, "It
should be evident, though, that such techniques are implementation
dependent."

[...]

-- 
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]

#112386

Keith Thompson <kst-u@mib.org> writes:

> bartc <bc@freeuk.com> writes:
> [...]
>
>> I tried compiling this:
>>
>> int main(void){
>>    isspace(0);
>> }
>>
>> I get no messages at all from either of the two tccs I have on Windows
>> (0.9.26, 32- and 64-buit versions).
>
> That behavior is consistent with a conforming C90 compiler.
>
>> Same with isspace(0,0).  Same with isspace("abc").  So it's not just
>> assuming implicit int.
>
> Yes it is.  The C90 implicit int rule assumes that an undeclared
> function takes arguments of the (promoted) types in the call,
> and returns int.  (If that assumption is inconsistent with the
> actual definition, as it is for isspace(0,0) and isspace("abc"),
> the behavior is undefined.)
>
>> Putting in a declaration like this however:
>>
>>    int isspace(int);
>>
>> generates an error and warning respectively on those last two calls.
>
> Again, that's consistent with a conforming C90 compiler.  (Adding
> "#include <ctype.h>" should have the same effect.)

Thank you for jumping in and giving this explanation.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web