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 2 of 2 — ← Prev page 1 [2]

#112170

On 14/06/2017 02:13, 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?


Try this compiler** (choose either -32 or -64 version depending on your 
Tiny C):

https://github.com/bartg/langs/blob/master/bccproj/mcc32.c
https://github.com/bartg/langs/blob/master/bccproj/mcc64.c

Use tcc to compile it, eg:

   tcc mcc32.c -omcc.exe

Then run as:

   mcc program.c

You won't be able to run the result (as it needs extra bits and pieces, 
code is only for x64 etc), but can give a second opinion on code that 
apparently passes error-free with other compilers.

It will not tolerate any functions for which it hasn't seen a 
declaration. And will not compile isspace() without including ctype.h.

(Note this may fail on some programs even with the right headers, as the 
headers are incomplete.)

[** One of my own compilers]

-- 
bartc

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

#112198

bartc <bc@freeuk.com> writes:
> On 14/06/2017 02:13, 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?
>
>
> Try this compiler** (choose either -32 or -64 version depending on your 
> Tiny C):
>
> https://github.com/bartg/langs/blob/master/bccproj/mcc32.c
> https://github.com/bartg/langs/blob/master/bccproj/mcc64.c
>
> Use tcc to compile it, eg:
>
>    tcc mcc32.c -omcc.exe
>
> Then run as:
>
>    mcc program.c
>
> You won't be able to run the result (as it needs extra bits and pieces, 
> code is only for x64 etc), but can give a second opinion on code that 
> apparently passes error-free with other compilers.

Why would a second opinion be needed?  The standard is clear.

Under C90, calls to undeclared functions are permitted.  Under C99 and
C11, they're a constraint violation.  <stdio.h> and <stdlib.h> do not
declare isspace(); <ctype.h> does.

This:

#include <stdio.h>
#include <stdlib.h>
int main(void) {
    puts(isspace(' ') ? "OK" : "Huh?");
    return 0;
}

is a valid program with well defined behavior under C90, and violates
a constraint in C99 and C11.  An implementation that compiles it
with no diagnostic is not a conforming C99 or C11 implementation
(a bug if it claims to conform to C99 or C11).

Of course the solution for programmers is easy.  If you call isspace(),
add "#include <ctype.h>", even if your code is only intended to be
compiled as C90.

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

#112200

On 14/06/2017 17:35, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:

>> code is only for x64 etc), but can give a second opinion on code that
>> apparently passes error-free with other compilers.
> 
> Why would a second opinion be needed?

A second opinion from a compiler, that might give you a hint that 
another compiler might be too forgiving.

> The standard is clear.

On this point, what the standard says isn't helpful.

What IS helpful is that when a function call is used, the correct 
declaration for that declaration is visible.

While a compiler can't know for certain the declared signature is 
correct, other than checking the number and compatibility of arguments, 
at least it should complain if it's missing completely!

Some compilers will say nothing (tcc and DMC), some will just give a 
warning (that can be mixed up with harmless ones so can be missed), some 
will only generate an error when the right incantation of options.

A missing declaration should simply be an ERROR, full stop. If legacy 
code has missing declarations, then it needs to be fixed.

> Of course the solution for programmers is easy.  If you call isspace(),
> add "#include <ctype.h>", even if your code is only intended to be
> compiled as C90.

C90 was at fault too. Why allow something so sloppy? And potentially 
dangerous.

-- 
bartc

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

#112207

On Wednesday, June 14, 2017 at 11:47:41 AM UTC-5, Bart wrote:
> C90 was at fault too. Why allow something so sloppy? And potentially 
> dangerous.

The authors of the Standard did not want to imply that conforming compilers
should reject pre-existing code which was considered valid according to the
closest thing to a standard (The C Programming Language book).  It would have
been (and still would be) sensible to recognize a category of programs that
implementations could either accept or reject at their leisure, and regard
programs that call functions without declarations as being in that category.
The authors of the Standard, however, seem to have imagined a world where
every program would either be accepted by all implementations or rejected
by all of them, rather than recognizing that different implementations are
intended for different purposes and thus *should* behave differently.

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

#112209

supercat@casperkitty.com writes:
> On Wednesday, June 14, 2017 at 11:47:41 AM UTC-5, Bart wrote:
>> C90 was at fault too. Why allow something so sloppy? And potentially 
>> dangerous.
>
> The authors of the Standard did not want to imply that conforming compilers
> should reject pre-existing code which was considered valid according to the
> closest thing to a standard (The C Programming Language book).  It would have
> been (and still would be) sensible to recognize a category of programs that
> implementations could either accept or reject at their leisure, and regard
> programs that call functions without declarations as being in that category.
> The authors of the Standard, however, seem to have imagined a world where
> every program would either be accepted by all implementations or rejected
> by all of them, rather than recognizing that different implementations are
> intended for different purposes and thus *should* behave differently.

C90 compilers still exist.  Many compilers have options to make them
behave as C90 compilers.  If you want to compile code that calls
undeclared functions, you can use such a compiler or such an option.  No
additional categories are needed.

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

#112208

bartc <bc@freeuk.com> writes:
> On 14/06/2017 17:35, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> code is only for x64 etc), but can give a second opinion on code that
>>> apparently passes error-free with other compilers.
>> 
>> Why would a second opinion be needed?
>
> A second opinion from a compiler, that might give you a hint that 
> another compiler might be too forgiving.
>
>> The standard is clear.
>
> On this point, what the standard says isn't helpful.

I disagree.

> What IS helpful is that when a function call is used, the correct 
> declaration for that declaration is visible.

Yes, programmers should ensure that a correct declaration is visible for
each called function.  (C90 compilers are not necessarily helpful in
doing that.)

> While a compiler can't know for certain the declared signature is 
> correct, other than checking the number and compatibility of arguments, 
> at least it should complain if it's missing completely!

I agree -- and conforming C99 and C11 compilers do so.  C90 compilers
are not required to complain.

> Some compilers will say nothing (tcc and DMC), some will just give a 
> warning (that can be mixed up with harmless ones so can be missed), some 
> will only generate an error when the right incantation of options.
>
> A missing declaration should simply be an ERROR, full stop. If legacy 
> code has missing declarations, then it needs to be fixed.

I agree.

>> Of course the solution for programmers is easy.  If you call isspace(),
>> add "#include <ctype.h>", even if your code is only intended to be
>> compiled as C90.
>
> C90 was at fault too. Why allow something so sloppy? And potentially 
> dangerous.

Yes, the C90's implicit int rule was a problem.  That problem was solved
18 years ago by removing the implicit int rule in C99.  Not all
compilers conform to C99 or C11 requirements.

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

#112211

On 14/06/2017 18:21, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:

>> C90 was at fault too. Why allow something so sloppy? And potentially
>> dangerous.
> 
> Yes, the C90's implicit int rule was a problem.  That problem was solved
> 18 years ago by removing the implicit int rule in C99.  Not all
> compilers conform to C99 or C11 requirements.

Funny way of solving it, by either ignoring it or reporting a mere 
warning. All with compilers that have latest versions long after 1999.

 >> 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.)


But a program with no isspace declaration but these two calls:

   isspace(0,0);
   isspace("abc");

still compiles! Compilers don't seem bothered that, whatever the actual 
parameter type of isspace, it's being called in two inconsistent ways. 
One of them must be wrong.

With an implicit declaration, a compiler may need to assume the 
programmer knows what they're doing. But this code can't possibly be 
right. Yet the compiler let's it through with just a warning! And an 
innocuous sounding warning that says nothing about the contradictory 
sets of arguments.

(If I run this under MSVC, it crashes. Hidden away in a 100,000-line 
program, I would expect it to report an error.)

-- 
barct

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

#112215

bartc <bc@freeuk.com> writes:
> On 14/06/2017 18:21, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> C90 was at fault too. Why allow something so sloppy? And potentially
>>> dangerous.
>> 
>> Yes, the C90's implicit int rule was a problem.  That problem was solved
>> 18 years ago by removing the implicit int rule in C99.  Not all
>> compilers conform to C99 or C11 requirements.
>
> Funny way of solving it, by either ignoring it or reporting a mere 
> warning. All with compilers that have latest versions long after 1999.

Not all compilers produced after 1999 conform to the C99 or
C11 standard, and a non-fatal warning satisfies the standard's
requirement for a diagnostic.  Many compilers have an option to make
such diagnostics fatal.  If a warning isn't good enough for you,
find out how to make the error fatal.  Use a different compiler
if necessary.  If a compiler claims to conform to C99 and doesn't
issue at least a warning, submit a bug report -- to the compiler
provider, not to comp.lang.c.

[...]

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

#112378

On Thursday, June 15, 2017 at 3:12:08 AM UTC+9, Bart wrote:
> On 14/06/2017 18:21, Keith Thompson wrote:
> > bartc  writes:
> 
> >> C90 was at fault too. Why allow something so sloppy? And potentially
> >> dangerous.
> > 
> > Yes, the C90's implicit int rule was a problem.  That problem was solved
> > 18 years ago by removing the implicit int rule in C99.  Not all
> > compilers conform to C99 or C11 requirements.
> 
> Funny way of solving it, by either ignoring it or reporting a mere 
> warning. All with compilers that have latest versions long after 1999.

Compilers used to take a really long time to write.

(And, of course, even now, you sometimes still want to compile code 
that was written way back when.)

>  >> 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.)
> 
> 
> But a program with no isspace declaration but these two calls:
> 
>    isspace(0,0);
>    isspace("abc");
> 
> still compiles! Compilers don't seem bothered that, whatever the actual 
> parameter type of isspace, it's being called in two inconsistent ways. 
> One of them must be wrong.

Erm, the linker might be directed to link to a (non-standard-library) 
function that looks something like this:

   int isspace( char * p1, ... )
   {
      ...
      if ( p1 == NULL )
      {
         /* Do something special with other parameters */
      }
      ...
   }

And NULL for the particular compiler might be an unadorned 0.

(I really should check the grammar first, but I think you can see what 
I mean.) 

> With an implicit declaration, a compiler may need to assume the 
> programmer knows what they're doing. But this code can't possibly be 
> right. Yet the compiler let's it through with just a warning! And an 
> innocuous sounding warning that says nothing about the contradictory 
> sets of arguments.

The compiler and the linker are the same tool in a lot of implementations
these days. It used to be that most were separate tools.

Either way, it's a separate phase. Now that we know how to make 
different languages cooperate better, communication between the phases 
is a bit better. Still not perfect.
 
> (If I run this under MSVC, it crashes. Hidden away in a 100,000-line 
> program, I would expect it to report an error.)

Of course it crashes. 

Unless you tell it to link to a non-standard library that contains an
isspace() function that can deal with a NULL being passed on the first 
call. 

The second parameter doesn't really figure in here, either way, on 
most run-times. Passing parameters on the stack is like that. Too few
parameters can be a serious problem, especially when the return pointer
gets interpreted as an array index or something even more dangerous, 
but extra parameters are usually just ignored because the calling 
function cleans up the stack.

Oh. C has variable parameter lists, so most (for some meaning of "most")
C compilers have the calling function clean up the stack.

If the called function cleans up the stack, yeah, the extra parameter 
would likely cause crashes with many compilers. 

(Again, I can imagine an exception, a run-time architecture in which 
the called function cleans up the stack, but the calling function tells 
it how many bytes of parameters need to be removed.)

Lots of different things exist in this world.

--
Joel Rees

Trying to re-invent the industry all by myself:
http://defining-computers.blogspot.jp/

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

#112401

On Friday, June 16, 2017 at 7:56:37 PM UTC-5, joel wrote:
> The second parameter doesn't really figure in here, either way, on 
> most run-times. Passing parameters on the stack is like that. Too few
> parameters can be a serious problem, especially when the return pointer
> gets interpreted as an array index or something even more dangerous, 
> but extra parameters are usually just ignored because the calling 
> function cleans up the stack.
> 
> Oh. C has variable parameter lists, so most (for some meaning of "most")
> C compilers have the calling function clean up the stack.

Most microcomputer C implementations use a calling convention where the code
that calls a function is responsible for cleaning up whatever arguments it
places on the stack; many microcomputer implementations of other languages
make the called code responsible for cleaning up the arguments it's expecting
to receive.  It's not uncommon for functions to either use or ignore their
later arguments, based upon the values of earlier ones; in the days before
prototypes, the C approach allowed calling code to omit arguments that the
calling function wasn't going to use, thus improving efficiency.

An implementation that requires called functions to clean up their arguments
can still support variadic functions, if the caller places all the arguments
into a temporary structure and passes a pointer to that.  On such a
platform, a function like fprintf would be processed as something equivalent
to:

    int fprintf(FILE *f, char const *format, void *arguments);

except that the compiler generating calling code would automatically create
a structure containing whatever arguments were required and pass a structure
to that.  The requirement to prototype functions with variadic argument
lists stems from the need to let implementations know when they will need to
consolidate their arguments into a single structure and pass a pointer to
that.

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

#112442

On Sat, 17 Jun 2017 10:20:44 -0700 (PDT), supercat@casperkitty.com
wrote:

>On Friday, June 16, 2017 at 7:56:37 PM UTC-5, joel wrote:
>> The second parameter doesn't really figure in here, either way, on 
>> most run-times. Passing parameters on the stack is like that. Too few
>> parameters can be a serious problem, especially when the return pointer
>> gets interpreted as an array index or something even more dangerous, 
>> but extra parameters are usually just ignored because the calling 
>> function cleans up the stack.
>> 
>> Oh. C has variable parameter lists, so most (for some meaning of "most")
>> C compilers have the calling function clean up the stack.
>
>Most microcomputer C implementations use a calling convention where the code
>that calls a function is responsible for cleaning up whatever arguments it
>places on the stack; many microcomputer implementations of other languages
>make the called code responsible for cleaning up the arguments it's expecting
>to receive.  It's not uncommon for functions to either use or ignore their
>later arguments, based upon the values of earlier ones; in the days before
>prototypes, the C approach allowed calling code to omit arguments that the
>calling function wasn't going to use, thus improving efficiency.
>
>An implementation that requires called functions to clean up their arguments
>can still support variadic functions, if the caller places all the arguments
>into a temporary structure and passes a pointer to that.  On such a
>platform, a function like fprintf would be processed as something equivalent
>to:
>
>    int fprintf(FILE *f, char const *format, void *arguments);
>
>except that the compiler generating calling code would automatically create
>a structure containing whatever arguments were required and pass a structure
>to that.  The requirement to prototype functions with variadic argument
>lists stems from the need to let implementations know when they will need to
>consolidate their arguments into a single structure and pass a pointer to
>that.


The advantage of callee cleanup is that it may be faster than caller
cleanup.  At least some implementations that go that route for
non-variadic functions use a different, caller clearup, calling
convention for variadic functions.  Usually that would be rather
simpler than creating a structure like that.  An example is the
default thiscall convention MSVC uses for C++ methods: it's caller
cleanup except for variadic functions (where it's callee cleanup).

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

#112582

On Sunday, June 18, 2017 at 12:25:53 AM UTC-5, robert...@yahoo.com wrote:
> The advantage of callee cleanup is that it may be faster than caller
> cleanup.  At least some implementations that go that route for
> non-variadic functions use a different, caller clearup, calling
> convention for variadic functions.  Usually that would be rather
> simpler than creating a structure like that.  An example is the
> default thiscall convention MSVC uses for C++ methods: it's caller
> cleanup except for variadic functions (where it's callee cleanup).

There are relatively few platforms where callee cleanup is faster, but it
seems to be popular even on platforms where it isn't.  I suspect its
popularity on those platforms stems from the fact that callers usually
outnumber callees by a generous margin, and code size is usually more
important than execution speed.

I suspect microcomputer and high-end compilers may have historically taken
a different attitudes toward such trade-offs because microcomputers tried
to do as much as possible with a minimum of RAM.  If saving 25% on RAM would
make a high-end application run 25% slower, that would increase by 25% the
number of machines necessary to process a given workload.  For many kinds
of microcomputer applications, however, being able to run a program at
almost any speed with a certain amount of RAM would be better than being
unable to run it at all.

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

#112656

On Mon, 19 Jun 2017 09:01:44 -0700 (PDT), supercat@casperkitty.com
wrote:

>On Sunday, June 18, 2017 at 12:25:53 AM UTC-5, robert...@yahoo.com wrote:
>> The advantage of callee cleanup is that it may be faster than caller
>> cleanup.  At least some implementations that go that route for
>> non-variadic functions use a different, caller clearup, calling
>> convention for variadic functions.  Usually that would be rather
>> simpler than creating a structure like that.  An example is the
>> default thiscall convention MSVC uses for C++ methods: it's caller
>> cleanup except for variadic functions (where it's callee cleanup).
>
>There are relatively few platforms where callee cleanup is faster, but it
>seems to be popular even on platforms where it isn't.  I suspect its
>popularity on those platforms stems from the fact that callers usually
>outnumber callees by a generous margin, and code size is usually more
>important than execution speed.


Given the behavior of caches, smaller code is often faster code. Also,
in some implementations callee cleanup may reduce the number of
modification to the stack/frame pointer, and the change happens
earlier as well, reducing its impact on subsequent dependencies.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web