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

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

Some ideas about c?

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

Contents

  Some ideas about c? Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-17 23:23 +0300
    Re: Some ideas about c? Ian Collins <ian-news@hotmail.com> - 2017-05-18 08:40 +1200
    Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-17 23:00 +0200
      Re: Some ideas about c? supercat@casperkitty.com - 2017-05-17 14:59 -0700
        Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 00:08 +0200
          Re: Some ideas about c? supercat@casperkitty.com - 2017-05-17 22:09 -0700
            Re: Some ideas about c? Ian Collins <ian-news@hotmail.com> - 2017-05-18 18:22 +1200
            Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 12:36 +0200
              Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 03:53 -0700
                Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 14:24 +0200
                  Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 08:37 -0400
                    Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 05:47 -0700
                    Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 15:20 +0200
                      Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 06:28 -0700
                      Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-18 13:56 +0000
                        Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-18 16:30 +0200
                          Re: Some ideas about c? Thiago Adams <thiago.adams@gmail.com> - 2017-05-18 07:45 -0700
                            Re: Some ideas about c? Richard Heathfield <rjh@cpax.org.uk> - 2017-05-18 16:08 +0100
                              Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 08:15 -0700
                                Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 11:46 -0400
                                  Re: Some ideas about c? Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-18 21:33 +0300
                                    Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 15:29 -0400
                                    Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-19 01:23 +0200
                                      Re: Some ideas about c? Thiago Adams <thiago.adams@gmail.com> - 2017-05-18 18:12 -0700
                              Re: Some ideas about c? Thiago Adams <thiago.adams@gmail.com> - 2017-05-18 10:08 -0700
                            Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-19 00:39 +0200
                              Re: Some ideas about c? Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-19 14:27 +0300
                                Re: Some ideas about c? David Brown <david.brown@hesbynett.no> - 2017-05-19 13:41 +0200
                                  Re: Some ideas about c? Richard Heathfield <rjh@cpax.org.uk> - 2017-05-19 13:04 +0100
                                  Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 10:00 -0700
                                Re: Some ideas about c? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-19 14:14 +0200
                      Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 11:33 -0400
                        Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 08:47 -0700
                        Re: Some ideas about c? supercat@casperkitty.com - 2017-05-18 08:48 -0700
                          Re: Some ideas about c? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-18 09:02 -0700
                            Re: Some ideas about c? supercat@casperkitty.com - 2017-05-18 10:52 -0700
                          Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 15:35 -0400
                            Re: Some ideas about c? supercat@casperkitty.com - 2017-05-18 14:01 -0700
                              Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 17:38 -0400
                                Re: Some ideas about c? supercat@casperkitty.com - 2017-05-18 15:54 -0700
                                  Re: Some ideas about c? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-18 22:17 -0400
                  Re: Some ideas about c? John Bode <jfbode1029@gmail.com> - 2017-05-18 08:06 -0700
                    Re: Some ideas about c? John Bode <jfbode1029@gmail.com> - 2017-05-18 09:17 -0700
    Re: Some ideas about c? fir <profesor.fir@gmail.com> - 2017-05-17 14:34 -0700
      Re: Some ideas about c? Vassilis Spiliopoulos <vassilis@vask1lux.de> - 2017-05-18 16:16 +0300
    Re: Some ideas about c? Cholo Lennon <chololennon@hotmail.com> - 2017-05-18 10:26 -0300
    Re: Some ideas about c? John Bode <jfbode1029@gmail.com> - 2017-05-18 07:36 -0700
      Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-18 18:23 +0000
        Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-18 21:51 +0100
          Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 12:38 +0000
            Re: Some ideas about c? supercat@casperkitty.com - 2017-05-19 07:44 -0700
              Re: Some ideas about c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 16:45 +0100
                Re: Some ideas about c? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-19 21:59 -0700
              Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 10:06 -0700
                Re: Some ideas about c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 18:18 +0100
                  Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 11:59 -0700
                    Re: Some ideas about c? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-19 21:05 +0100
            Re: Some ideas about c? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-19 12:42 -0400
              Re: Some ideas about c? Richard Heathfield <rjh@cpax.org.uk> - 2017-05-19 17:54 +0100
              Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-19 18:52 +0100
            Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-19 18:51 +0100
              Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 18:55 +0000
                Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-19 19:58 +0100
                Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 12:12 -0700
              Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 12:01 -0700
      Re: Some ideas about c? Ian Collins <ian-news@hotmail.com> - 2017-05-19 08:22 +1200
        Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-18 21:53 +0100
        Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 12:36 +0000
          Re: Some ideas about c? Gareth Owen <gwowen@gmail.com> - 2017-05-19 18:54 +0100
            Re: Some ideas about c? scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 18:58 +0000
              Re: Some ideas about c? Keith Thompson <kst-u@mib.org> - 2017-05-19 12:18 -0700

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

#110352

On 5/18/2017 6:54 PM, supercat@casperkitty.com wrote:
> On Thursday, May 18, 2017 at 4:38:19 PM UTC-5, Jerry Stuckle wrote:
>> On 5/18/2017 5:01 PM, supercat wrote:
>>> On 1980s Macintosh C compilers, a string literal starting with "\p"
>>> would be preceded by a length byte.  An absolutely essential extension
>>> when writing Macintosh applications, since the OS functions all expected
>>> pointers to length-prefixed strings.
>>
>> So, who cares what non-compliant compilers did?  A properly designed C
>> library would handle the specific OS requirement without breaking
>> conformance.
> 
> The Standard allows compilers to add additional backslash escapes as an
> extension.  The implementation came with bundled libraries for file I/O,
> but and I think its OS interface libraries included some functions that
> would convert C strings to Pascal strings and then perform an OS request
> (e.g. to render a string onto a GrafPort using its current selected font)
> but calling a function which would copy a C string to a separate buffer
> and then pass that to the OS was slower than simply using Pascal strings
> when communicating with OS code that needed them.
>

An extension is not standard C.

>>> Functions which needed to operate on strings longer than 256 bytes generally
>>> used handles to objects which the OS could relocate as needed so as to avoid
>>> fragmentation.
>>
>> See above.
> 
> Using OS-managed handles made it possible to grow and shrink large strings
> without fragmentation killing everything, at least if there weren't too many
> immovable objects fragmenting the free store.  While code could use malloc,
> realloc, and free, application performance would often be better if programs
> used the system's relocatable memory handles instead when practical.
> 

Sure.  But it is not standard C, and is not compatible with any other C
compilers.

>>> They're pretty terrible for most purposes.  If one wants to concatenate
>>> two strings and doesn't knows the lengths, memcpy() will be faster and in
>>> pretty much every way better than strcat().  If one doesn't know the
>>> lengths, but somehow knows that the destination is big enough, strcat()
>>> might be usable I suppose, but using strlen on strings whose length isn't
>>> known, ensuring that adequate space exists, and then using memcpy, seems
>>> like a better approach than giving the strings to strcat and hoping nothing
>>> blows up.
>>>
>>
>> C is not a great language for handling strings.  But adding a length to
>> the string wouldn't make it any better.
> 
> Allowing the byte identified by a "string pointer" to indicate whether the
> pointer identifies:
> 
>   A string of a given length that precisely fills its buffer
> 
>   An empty buffer of a given size
> 
>   A buffer of a given size which is not completely full, and has the number
>   of slack bytes stored at the end.
> 
>   A string descriptor which starts with a couple bytes describing what it
>   is, along with a pointer to the buffer, its size, the length of string
>   therein, and optional information allowing the buffer to be resized.
> 

A string is not the same as a buffer - in *ANY* language.  And when the
string has a length as the first two bytes (one more byte than a null
terminator), that length is the length of the string, not the buffer.

And if you have a string descriptor, you are talking a lot more than a
single terminating null byte.

> would make it possible to have a function like "strcat" whose first argument
> can be a fixed-size buffer, a descriptor of a fixed-size block of storage,
> or a descriptor for a resizable block of storage, and whose second argument
> could be any kind of string or string descriptor, without having to pass it
> anything except two string pointers.  A string buffer would have to be
> initialized prior to use, but that would only require storing 1-5 bytes to
> it, depending upon length.
> 

A fixed-sized buffer would limit any operation to the length of that
buffer, as well as requiring all operations to use that size buffer.
Both are severely limiting factors.

And having to initialize a string buffer before using string function is
another problem.

> The biggest obstacle to using such strings is the lack of any decent way
> to include string literals in-line within C code.  If the language supported
> static compound literals and a construct like:
> 
>    (constExpr ? (void*)&staticCompoundLiteral1 : (void*)&staticCompoundLiteral2)
> 
> would only generate one of them, code could be written more cleanly using
> prefixed strings than C strings.
> 

There are a number of ways to include string literals in C code.  *Good*
C programmers know how to use the language.

>> And memcpy does not add the trailing null character.
> 
> It will copy any trailing null character which is present in the original if
> the null byte is included in the size.
> 

IFF you include the null character in the size.  If you don't, you are SOL.

>> We all know you don't like C.  So why don't you find a language you do
>> like and stop wasting bandwidth bitching about C?  No one here cares.
> 
> Low-level C is the best language for embedded systems.  Today's compiler
> writers, however, prefer to process a different language which is less
> suitable for such purposes.
> 

No, we all know you don't like C.  So why don't you find a language you
do like and stop wasting bandwidth bitching about C?  No one here cares.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#110289

On Thursday, May 18, 2017 at 7:27:11 AM UTC-5, GOTHIER Nathan wrote:
> On Thu, 18 May 2017 03:53:29 -0700 (PDT)
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> 
> > Templates are  efficient.
> > The problem is that when a type is templated, you don't know what 
> > symbols ans operations the type needs to support. This isn't such a 
> > problem with STL - once you know you need a default constructor and a 
> > copy constructor and a move constructor for heavyweight objects, you 
> > know. But when non-standard library programmers create their own 
> > generics, it becomes a big problem.
> 
> Templates are as efficient as a generic logic can be but a specifically
> designed interface is way more efficient. It's like pretending a general
> purpose circuit such as a microprocessor is the only way to process all 
> kind of data but why do so many people buy graphic cards?
> 

You *can* provide specialized handling for specific types in a template
definition, so if you need to do something special for floating point
types vs. integral types, that's not a problem.  

> The only reason for the STL to be is to lower the bar for unskilled
> programmers. 
> 

Or, maybe, it's to allow skilled programmers to focus on the actual problem
and not worry about the small stuff.

With the std::copy function in <algorithm>, I can:

 - Copy the contents of one container to another;
 - Write the contents of a container to an output stream;
 - Read the contents of an input stream into a container;
 - Write the contents of an input stream to an output stream;

without having to implement any kind of helper function (as with qsort)
or other specialized logic.  That's a *huge* productivity win IMO.

Container types do their own memory management, meaning *I don't have to*.
That frees me up to worry about the actual *problem I'm trying to solve*.

C++ gives you options to do things the easy way or the hard way, depending
on your particular needs.  C requires you to do everything the hard way.
That's not necessarily a win.  

> 
> > The malloc family of functions are special. A pure function may need to 
> > call malloc and free. Any other subroutines can be supplied or folded 
> > into the main function.
> > But really you want standard math functions and a few standard string 
> > handling functions, the first because they are a pain to write, the 
> > second because otherwise everyone has their own version of strcpy() 
> > which accepts parameters in a different order or copies to and from 
> > dynamic memory or takes a length parameter. Any of those things you can 
> > build a case for, but it's best to stick to a standard.
> 
> I doubt that all C programmers need float, complex type or even string 
> utilities.

You'd be hard-pressed to find a C programmer who *doesn't* need to do string
processing of some sort.  

> 
> Once more, if it's difficult to write it doesn't mean it needs to be 
> standard but only you need a library to avoid the pain.
> 
> Do we need GTK+ to be included in the C standard? I don't think so.

Criteria for inclusion in the standard library:

 - Abstract away system-specific behavior: I/O, memory management, file
   management, date and time processing, signal handling, locale;
 - Maximize portability by providing a standard interface for very common
   operations: string and character processing, math operations;

Far, far, *far* more people do strcmp() on a daily basis than mess with
GUIs of any sort, much less a specific toolkit like GTK+.  

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

#110307

On Thursday, May 18, 2017 at 10:06:38 AM UTC-5, John Bode wrote:

[snip]

> 
> With the std::copy function in <algorithm>, I can:
> 
>  - Copy the contents of one container to another;
>  - Write the contents of a container to an output stream;
>  - Read the contents of an input stream into a container;
>  - Write the contents of an input stream to an output stream;
> 
> without having to implement any kind of helper function (as with qsort)
> or other specialized logic.  That's a *huge* productivity win IMO.
> 

Actually, now that I think about it, that's not true - for anything 
that isn't a primitive type, you *do* need to implement some additional 
code.  But my point still stands, I think.  It's a major productivity win 
over having to write multiple implementations of what is basically the same 
operation.

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

#110238

W dniu środa, 17 maja 2017 22:24:36 UTC+2 użytkownik Vassilis Spiliopoulos napisał:
> Well I am a newbie yet I have not decided yet if I should start c or c++
> Please tell me your ideas
> 

learn slightly c++ to know what it is and never touch it again (like me)

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

#110273

On 5/18/2017 12:34 AM, fir wrote:
> W dniu środa, 17 maja 2017 22:24:36 UTC+2 użytkownik Vassilis Spiliopoulos napisał:
>> Well I am a newbie yet I have not decided yet if I should start c or c++
>> Please tell me your ideas
>>
>
> learn slightly c++ to know what it is and never touch it again (like me)
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
I forgot to tell you what I want to do with C.I want to edit source 
codes and contribute to dogecoin, bitcoin and linux as well as reverse 
engineer some operating system kernels like windows ce and others.
So I have general purposes, I just want to be able to put an idea into 
action.

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

#110276

On 17/05/17 17:23, Vassilis Spiliopoulos wrote:
> Well I am a newbie yet I have not decided yet if I should start c or c++
> Please tell me your ideas
> 

Ask this question in comp.lang.c++ and you will get a totally different 
set of answers (I prefer C++, but this not the place to say it)


-- 
Cholo Lennon
Bs.As.
ARG

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

#110285

On Wednesday, May 17, 2017 at 3:24:36 PM UTC-5, Vassilis Spiliopoulos wrote:
> Well I am a newbie yet I have not decided yet if I should start c or c++
> Please tell me your ideas
> 
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com

C is definitely the simpler language of the two, and by that metric easier 
to learn.  It doesn't give you much in the way of a toolkit, and the 
abstractions it provides are fairly low-level (streams and pointers are 
basically it).

C++ has more tools that will make you more productive early on, but some
concepts may not be immediately intuitive, and to use it effectively you
kind of have to learn a lot of different concepts up front (classes, 
templates, and now lambdas).  

I would not recommend either one for *learning how to program*.  Neither 
language was designed with teaching in mind, and some concepts in each
are *deeply* non-intuitive.  Both language specifications are fairly loose 
in places, allowing you to write code that will build and run, but its 
behavior will not be predictable or repeatable.  

I've started comparing learning how to program in C with learning how to
drive in a Lamborghini Countach.  Fast, difficult to drive, and if you
let your attention wander for more than a few seconds you're spinning
into the ditch.  It's not an appropriate car for student drivers, and C
is not an appropriate language to teach basic programming.  

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

#110320

ram@zedat.fu-berlin.de (Stefan Ram) writes:

>John Bode <jfbode1029@gmail.com> writes:
>>C is definitely the simpler language of the two, and by that metric easier 
>
>  It might be easier to /learn/. But is it also easier to apply?
>
>  One example: Write a program, that reads in a line from the
>  console and then echoes the same line to the console again.
>
>  C++:
>
>#include <iostream>
>#include <ostream>
>#include <string>
>
>int main() 
>{ ::std::string line;
>  getline( ::std::cin, line );
>  ::std::cout << line << '\n'; }

>
>  How can a beginner write something like this in C without
>  the risk of a buffer overflow or arbitrary limitations on
>  the length and without having to think about distracting
>  low-level details?

I'd argue that a beginner _should_ be learning about
low-level details before ever learning C++.

#include <stdio.h>

int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer), stdin), stdout); }

For that matter, this code also compiles just fine as C++ code.

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

#110331

scott@slp53.sl.home (Scott Lurndal) writes:

> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
> stdin), stdout); }

Great.  Except it doesn't work if the input line is too big.

> For that matter, this code also compiles just fine as C++ code.

But doesn't run fine as either.  I assume, you knew that.

So you've demonstrated how its marginally simpler to write incorrect
code in C than correct code in C++.

Erm ... well done?

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

#110375

Gareth Owen <gwowen@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>> stdin), stdout); }
>
>Great.  Except it doesn't work if the input line is too big.

Sure it does.  It just truncates it.  And the programmer is, of
course, aware of that.

>
>> For that matter, this code also compiles just fine as C++ code.
>
>But doesn't run fine as either.  I assume, you knew that.

Actually, it does compile and run using the C++ compiler.

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

#110378

On Friday, May 19, 2017 at 7:38:13 AM UTC-5, Scott Lurndal wrote:
> Gareth Owen writes:
> >scott writes:
> >
> >> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
> >> stdin), stdout); }
> >
> >Great.  Except it doesn't work if the input line is too big.
> 
> Sure it does.  It just truncates it.  And the programmer is, of
> course, aware of that.

It doesn't truncate lines; it wraps them.  Sometimes that's desirable, and
sometimes not.  A function which behaved like fgets() but provided a choice
of behaviors (truncate, wrap, or trap/signal) would have been helpful, but
fgets is what it is.

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

#110382

supercat@casperkitty.com writes:

> On Friday, May 19, 2017 at 7:38:13 AM UTC-5, Scott Lurndal wrote:
>> Gareth Owen writes:
>> >scott writes:
>> >
>> >> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>> >> stdin), stdout); }
>> >
>> >Great.  Except it doesn't work if the input line is too big.
>> 
>> Sure it does.  It just truncates it.  And the programmer is, of
>> course, aware of that.
>
> It doesn't truncate lines; it wraps them.  Sometimes that's desirable, and
> sometimes not.  A function which behaved like fgets() but provided a choice
> of behaviors (truncate, wrap, or trap/signal) would have been helpful, but
> fgets is what it is.

Yes, strange is what it is[1].  But it's possible to write a truncating
version that doesn't scan for the newline:

  char *fgets_truncate(char *buf, int size, FILE *fp)
  {
       buf[size - 1] = !0; /* anything but 0 will do */
       if (!fgets(buf, size, fp))
            return NULL;
       else if (buf[size - 1] == 0 && buf[size - 2] != '\n')
            for (int c; (c = fgetc(fp)) != '\n' && c != EOF;);
       return buf;
  }

It's handy to know this trick, since I've see a lot of code that uses,
say, strchr(buf, '\n') after the call.  (I've added some for-abuse for
good measure!)

--------
[1] It does not take a size_t size, and it usually returns something you
know (the buffer) rather than something you'd like to know (for example,
how many bytes were read).
-- 
Ben.

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

#110440

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> supercat@casperkitty.com writes:
>
>> On Friday, May 19, 2017 at 7:38:13 AM UTC-5, Scott Lurndal wrote:
>>> Gareth Owen writes:
>>>> scott writes:
>>>>
>>>>> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>>>>> stdin), stdout); }
>>>>
>>>> Great.  Except it doesn't work if the input line is too big.
>>>
>>> Sure it does.  It just truncates it.  And the programmer is, of
>>> course, aware of that.
>>
>> It doesn't truncate lines;  it wraps them.  Sometimes that's desirable, and
>> sometimes not.  A function which behaved like fgets() but provided a choice
>> of behaviors (truncate, wrap, or trap/signal) would have been helpful, but
>> fgets is what it is.
>
> Yes, strange is what it is[1].  But its possible to write a truncating
> version that doesn't scan for the newline:
>
>   char *fgets_truncate(char *buf, int size, FILE *fp)
>   {
>        buf[size - 1] = !0; /* anything but 0 will do */
>        if (!fgets(buf, size, fp))
>             return NULL;
>        else if (buf[size - 1] == 0 && buf[size - 2] != '\n')
>             for (int c; (c = fgetc(fp)) != '\n' && c != EOF;);
>        return buf;
>   }
>
> It's handy to know this trick, since I've see a lot of code that uses,
> say, strchr(buf, '\n') after the call.  (I've added some for-abuse for
> good measure!)

Oh but you have a wonderful function to do the scanning for
you (no pun intended).  Take out the for() and put in

        fgets_truncate( (char[16]){0}, 16, fp );

leaving no need for 'int c;' or comparing c to EOF.

(All tongue firmly in cheek, in case that needs saying.)

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

#110392

supercat@casperkitty.com writes:
> On Friday, May 19, 2017 at 7:38:13 AM UTC-5, Scott Lurndal wrote:
>> Gareth Owen writes:
>> >scott writes:
>> >
>> >> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>> >> stdin), stdout); }
>> >
>> >Great.  Except it doesn't work if the input line is too big.
>> 
>> Sure it does.  It just truncates it.  And the programmer is, of
>> course, aware of that.
>
> It doesn't truncate lines; it wraps them.  Sometimes that's desirable, and
> sometimes not.  A function which behaved like fgets() but provided a choice
> of behaviors (truncate, wrap, or trap/signal) would have been helpful, but
> fgets is what it is.

No, it doesn't wrap.

The program reads and prints a single line, discarding any remaining
input.  If the line is longer than 512 characters, including the
trailing newline, it prints only the first 512 characters and discards
the rest.  (Which means that the output might not contain a terminating
newline even if the input does.)

If the fputs(fgets(...)) call were in a loop, rather than being called
just once, it would copy the entire content of stdin to stdout.
Remember that fputs() doesn't add a newline.

The original problem statement was:

    Write a program, that reads in a line from the console and then
    echoes the same line to the console again.

The program assumes, perhaps incorrectly, that stdin and stdout
are associated with "the console".

A correct implementation of that requirement could read a character
at a time, stopping after printing a '\n' or reaching end-of-file.

If course if you need to do some additional processing on each line,
it gets a bit more complicated.

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

#110394

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

> supercat@casperkitty.com writes:
>> On Friday, May 19, 2017 at 7:38:13 AM UTC-5, Scott Lurndal wrote:
>>> Gareth Owen writes:
>>> >scott writes:
>>> >
>>> >> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>>> >> stdin), stdout); }
>>> >
>>> >Great.  Except it doesn't work if the input line is too big.
>>> 
>>> Sure it does.  It just truncates it.  And the programmer is, of
>>> course, aware of that.
>>
>> It doesn't truncate lines; it wraps them.  Sometimes that's desirable, and
>> sometimes not.  A function which behaved like fgets() but provided a choice
>> of behaviors (truncate, wrap, or trap/signal) would have been helpful, but
>> fgets is what it is.
>
> No, it doesn't wrap.
>
> The program reads and prints a single line, discarding any remaining
> input.  If the line is longer than 512 characters, including the
> trailing newline, it prints only the first 512 characters and discards
> the rest.  (Which means that the output might not contain a terminating
> newline even if the input does.)

I found this description a bit confusing so I'll offer a clarification.
Instead of "and discards the rest" I'd say "and leaves the rest to be
read by later input calls".

Discarded input sounds to me like input lost forever.

<snip>
-- 
Ben.

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

#110407

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> supercat@casperkitty.com writes:
>>> On Friday, May 19, 2017 at 7:38:13 AM UTC-5, Scott Lurndal wrote:
>>>> Gareth Owen writes:
>>>> >scott writes:
>>>> >
>>>> >> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>>>> >> stdin), stdout); }
>>>> >
>>>> >Great.  Except it doesn't work if the input line is too big.
>>>> 
>>>> Sure it does.  It just truncates it.  And the programmer is, of
>>>> course, aware of that.
>>>
>>> It doesn't truncate lines; it wraps them.  Sometimes that's desirable, and
>>> sometimes not.  A function which behaved like fgets() but provided a choice
>>> of behaviors (truncate, wrap, or trap/signal) would have been helpful, but
>>> fgets is what it is.
>>
>> No, it doesn't wrap.
>>
>> The program reads and prints a single line, discarding any remaining
>> input.  If the line is longer than 512 characters, including the
>> trailing newline, it prints only the first 512 characters and discards
>> the rest.  (Which means that the output might not contain a terminating
>> newline even if the input does.)
>
> I found this description a bit confusing so I'll offer a clarification.
> Instead of "and discards the rest" I'd say "and leaves the rest to be
> read by later input calls".
>
> Discarded input sounds to me like input lost forever.

Yes, the input is lost forever when the program (shown above in its
entirety but missing `#include <stdio.h>` terminates.

I suppose another program executed after this one could read the input,
but that's outside the scope of C.

I think people are assuming that the fputs(fgets(...)) line is meant to
be part of some larger program.  I'm not making that assumption, and the
original problem description doesn't imply it.

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

#110413

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> supercat@casperkitty.com writes:
>>>> On Friday, May 19, 2017 at 7:38:13 AM UTC-5, Scott Lurndal wrote:
>>>>> Gareth Owen writes:
>>>>> >scott writes:
>>>>> >
>>>>> >> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>>>>> >> stdin), stdout); }
>>>>> >
>>>>> >Great.  Except it doesn't work if the input line is too big.
>>>>> 
>>>>> Sure it does.  It just truncates it.  And the programmer is, of
>>>>> course, aware of that.
>>>>
>>>> It doesn't truncate lines; it wraps them.  Sometimes that's desirable, and
>>>> sometimes not.  A function which behaved like fgets() but provided a choice
>>>> of behaviors (truncate, wrap, or trap/signal) would have been helpful, but
>>>> fgets is what it is.
>>>
>>> No, it doesn't wrap.
>>>
>>> The program reads and prints a single line, discarding any remaining
>>> input.  If the line is longer than 512 characters, including the
>>> trailing newline, it prints only the first 512 characters and discards
>>> the rest.  (Which means that the output might not contain a terminating
>>> newline even if the input does.)
>>
>> I found this description a bit confusing so I'll offer a clarification.
>> Instead of "and discards the rest" I'd say "and leaves the rest to be
>> read by later input calls".
>>
>> Discarded input sounds to me like input lost forever.
>
> Yes, the input is lost forever when the program (shown above in its
> entirety but missing `#include <stdio.h>` terminates.

OK.  But it still sounds too active for me.  Something other than the
program probably discards the input.  I prefer to think of it as ignored
by the program.

<snip>
-- 
Ben.

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

#110387

On 05/19/2017 08:38 AM, Scott Lurndal wrote:
> Gareth Owen <gwowen@gmail.com> writes:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>>> stdin), stdout); }
>>
>> Great.  Except it doesn't work if the input line is too big.
>
> Sure it does.  It just truncates it.  And the programmer is, of
> course, aware of that.

The C++ code that it supposedly replaced had no such behavior. 
Therefore, it fails to be a proper replacement for that code.

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

#110390

On 19/05/17 17:42, James R. Kuyper wrote:
> On 05/19/2017 08:38 AM, Scott Lurndal wrote:
>> Gareth Owen <gwowen@gmail.com> writes:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>>>> stdin), stdout); }
>>>
>>> Great.  Except it doesn't work if the input line is too big.
>>
>> Sure it does.  It just truncates it.  And the programmer is, of
>> course, aware of that.
>
> The C++ code that it supposedly replaced had no such behavior.
> Therefore, it fails to be a proper replacement for that code.

Agreed. In fact, I would be disappointed if a language that came /after/ 
C had no better way of gathering stdin data than C itself had. Thus, a 
replacement in C is going to be a little more involved than a one-liner.

A few years ago, several clc subscribers posted their attempts at 
reading an *entire* line from stdin (right up to the newline, regardless 
of how long the line was). There was never any consensus about what 
constituted the best interface, of course, but that's C programmers for you.

(Mine was the best. So there.)

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

#110400

"James R. Kuyper" <jameskuyper@verizon.net> writes:

> On 05/19/2017 08:38 AM, Scott Lurndal wrote:
>> Gareth Owen <gwowen@gmail.com> writes:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> int main() { char buffer[512]; fputs(fgets(buffer, sizeof(buffer),
>>>> stdin), stdout); }
>>>
>>> Great.  Except it doesn't work if the input line is too big.
>>
>> Sure it does.  It just truncates it.  And the programmer is, of
>> course, aware of that.
>
> The C++ code that it supposedly replaced had no such
> behavior. Therefore, it fails to be a proper replacement for that
> code.

Thank you James.  I kept going back to see if I'd missed something.

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

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

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

csiph-web