Improvement of stdio.h functions

[shiftleftplusone]

hi,
I would appreciate if the number of stdio.h functions for file access could be improved.
For file access we basically just have (file).print, println, .write, and just .read (by single bytes).
But fprintf and fscanf would be appriciated, too.

E.g.,that's why I just faked fgets() to something which mimics the ANSI function.
It's been programmed quick and dirty, but IMO it's already an improvement.
You may polish it up for your libs and add it for use by SD if you wish.

char * fgets ( char * str, int32_t num, File * stream ) {
  int32_t i;
  i=0;
  strcpy(str, "");
  while ( stream->available() && (i < num)   ) {  
     str[i]=stream->read() ;
     if(str[i] >=  ' ')  ++i;
     else
     if(str[i] == '\0') goto ok; // end of string: \0
     else
     if(str[i] == '\n')   {      // end of string: CR
         //str[i] = '\0';          // optional: overwrite CR by '\0'
         str[++i] = '\0';      // insert additional 0-termination after CR (== ANSI C)
         goto ok;
     }  
  } 
  ok: return(str);
}

function call: 
char sdata[30];
File myFile;
fgets ( sdata, 20, &myFile ); 
or
char * sptr;
sptr = fgets ( sdata, 20, &myFile ); 

I just am trying to mimic more functions using multiple variable parameter lists ( ... ) provided by

#include <stdarg.h>
#include <stdio.h>

e.g.,

char * fprintf(File * stream,  char fmtstr[], ... )

but of course it would be better to access the "real" stdio.h functionality instead of a faked and limited homebrewed one.

ps,
the source code gets always corrupted after uploading it here !! :(

[peabo7]

Your fgets doesn't do what real fgets does, so you should call it something else, if you use it at all.

There are several problems:

It has a buffer overrun because it doesn't pay attention to the num parameter.
It never detects end of file, because 0 is not the indicator for end of file (-1 is, which is why you need to read into a int16_t).
The handling of end of file returning NULL is quite specific, in the case where end of file happens before reading any characters.
The loop terminates prematurely if stream->available() returns 0.

Try this instead (not tested, you should test it).

char * fgets ( char * str, int32_t num, File * stream ) {
  int32_t i = 0;
  
  while (i < (num - 1)) { // got room for newline and terminating null?
    int16_t ch = stream->read();
    if (ch < 0) // end of file
      break;
    str[i++] = ch;
    if ('\n' == ch) // end of line
      break;
  }
  
  if (i) { // room in buffer for terminating null
    str[i] = 0;
    return str;
  }
  else
    return NULL; // buffer too small or immediate end of file
}

Peter Olson

[shiftleftplusone]

@peabo7:
thank you for your input, I'm just a beginner in using C, and hints a very much appreciated.

I have a question nevertheless:

You wrote
"It has a buffer overrun because it doesn't pay attention to the num parameter."
but I had coded in 1 line
"while ( stream->available() && (i < num) ) "
so num had been notified IMO very well - is that not true?
or would it have to be replaced just by
"while ( stream->available() && (i < (num-1) ) ) " instead ?

OTOH, getting "" returned instead of a NULL pointer was my intention because I supposed the handling of a NULL pointer in Sketch to be much more complicated IMO than just getting a nullstring "" instead. IMO "" could be tested very quickly instead of getting pointer address issues and being lead to Nirwana when processing the returned string instead further on (e.g., by itoa or sscanf or what ever). But I agree, in this specific case it had been called something slightly different, e.g. "fgets_" or something else.

[shiftleftplusone]

BTW, @devs:
although peabo7's function mimics the "real" fgets() very well, this is just why I appreciated to have full stdio.h and stdlib.h support by Sketch instead of having to fake all these functions by one self with a risc of severe failures. So why having to invent the wheel from the scratch? It's all here, by gpp. (CMIIW)
So my wish was to just provide full stdio.h and stdlib.h features, please!

[matthijskooijman]

I'm again confused. It seems that fgets is already available through libc (which is available and enabled by default):

matthijs@grubby:~$ grep fgets /usr/lib/avr/include/ -r
/usr/lib/avr/include/stdio.h:extern char        *fgets(char *__str, int __size, FILE *__stream);

The only thing that is not available, is default streams (stdin/stdout/stderr), since they make no sense on a microcontroller, or functions like fopen to get a FILE* pointing to a file, since there is no default filesystem.

I previously suggested, in another ticket, to use FDEV_SETUP_STREAM to create a custom FILE* that wraps Serial (or whatever Arduino Stream you want). Then you can just use the already available fgets, fprintf (and printf if you assign stdout).

Does this not satisfy your need? Do you perhaps not understand what I'm suggesting? Or are you of the opinion that such FILE*-creating code should be included with Arduino by default?

[shiftleftplusone]

2x yes ;)
1st, I do not understand your suggestion ;)
2nd, IMO SD files should be implemented to Sketch to work just the same as files usually work by C and the common stdio.h functions.
So then we simply could use the common gpp stdio.h to work with Arduino SD files. 8-)
(to be honest, I have no idea how this could be achieved) :-/

by SD,
(myfile).open will be substituted by => => fopen
(myFile).println => => fputs or fprintf (or what ever)
(myFile).readln (what not exists) => => fgets
and so on

[PaulStoffregen]

You really seem to have missed the concept that Arduino creates its own simplified APIs.

Arduino is designed to be a system that makes electronics easier for novices and hobbyists. These things are done differently from standard C for very good, very intentional reasons.

You're not the first person to come along and loudly insist Arduino should abandon its long-standing and very successful design, only because you personally want it to work the same way as other systems. You're not the first person to say Arduino's way is non-standard or technically inferior. Many others have come before you and made pretty much all these same arguments.

The obvious reality is Arduino is a very successful platform because is provides simplified APIs.

[shiftleftplusone]

I know that it IS different, but it's not the best way it is supposed to be.
C is C is C is C.
IMO Arduino is C and so it should work like C in the first line,
probably providing some stuff which could make it (additionally) a little simpler here and there.

So first of all comes full C compatibility (like SNSI C99 plus stdio.h plus stdlib.h,

and then (maybe) comes some additional stuff.

[PaulStoffregen]

No, you do not understand.

Arduino is Arduino which uses C internally. It should work like Arduino.

[shiftleftplusone]

here in my topic about Sketch enhancements it is about making Arduino work with stdio.h functionality like C does by standard.
So IMO (about which is the current topic) Arduino should be able to provide standard C compatibility.

Additionally of course it may provide additional features which makes it easier here and there to handle by hobbiists.

opening files by fopen is standard, so it should work with Arduino, same about fclose.
fprintf is standard for writing data to file, so it should work for Arduino.
fscanf is standard in C to read data from files, so it should work with Arduino.

If one likes to have addtionally SD-(myFile).println, why not? but that's secondary.

[PaulStoffregen]

No, it's is Arduino's primary API. You simply do not understand Arduino.

[shiftleftplusone]

I understand Arduino, but my topic is about enhancing Arduino by C compatibility.
I think this is the point which YOU don't understand ?
stdio.h is finally much more powerful than just file.write and file.read and file.println

[PaulStoffregen]

No, you obviously do not understand Arduino at all.

[shiftleftplusone]

well, maybe start reading at the TOP:
I just don't want Arduino Sketch to stay as crippled as it currently is !!

having just SD-myFile.read to to read data from SD files ist simply rediculous !!

opening files by fopen is standard, so it should work with Arduino, same about fclose.
fprintf and fputs are standard for writing data to file, so they should work for Arduino.
fscanf and fgets are standard in C to read data from files, so they should work with Arduino, too.

If one likes to have addtionally SD-(myFile).println, why not? but that's secondary. -
and I honestly don't see why myFile.println should be more convenient than fputs or fprintf ???

again:
what I wish acc. to the TOP is Arduino to support and provide full stdio.h functionality, basicly, additionally to the existing API, not exclusively!

clearerr
fclose
feof
ferror
fflush
fgetc
fgetpos
fgets
fopen
fprintf
fputc
fputs
fread
freopen
fscanf
fseek
fsetpos
ftell
fwrite
getc
getchar
gets
perror
printf
putc
putchar
puts
remove
rename
rewind
scanf
setbuf
setvbuf
snprintf
sprintf
sscanf
tmpfile
tmpnam
ungetc
vfprintf
vfscanf
vprintf
vscanf
vsnprintf
vsprintf
vsscanf

objects:

stderr
stdin
stdout

types:

FILE
fpos_t
size_t

macro constants:

BUFSIZ
EOF
FILENAME_MAX
FOPEN_MAX
L_tmpnam
NULL
TMP_MAX

[mbanzi]

@PaulStoffregen gets Arduino :) thanks Paul

[mikaelpatel]

Is this a discussion about the Arduino API? I always thought the API was an attempt at OOP/C++. I would really like to discussion some of the constructs and the usage of classes. I do not see the elegance that @PaulStoffregen seems to see. What I see is something that would not give computer science students a degree let alone work in industry :) Let us use some standard industry metrics and evaluate the Arduino core and libraries before doing some of the claims above. @vogonjeltz gets software standards and reuse.

Cheers!