I wonder if such style of coding is okay in c and how to do that,

let me explain I want load disk file into ram with just one function

call of my production

I defined

struct bytes

{

char* begin;

char* end; //end is a first char after the data

}

the function mallocs appriopriate ram ant then reads whole file into

it and thats all

 int get_file_size(FILE* file)
 {
  int seek_pos = ftell(file);
  fseek(file, 0, SEEK_END);
  int file_length = ftell(file) ;
  fseek(file, seek_pos, SEEK_SET);
 
  return file_length;
 }
 
 bytes read_file_and_alloc_bytes(char* file_name)
 {
  FILE * file = fopen(file_name, "rb");
   if(file == NULL)      ERROR_EXIT("\n input file %s not found", file_name);
 
  int file_length = get_file_size(file);
  char* data      = malloc(file_length);
 
  if(data == NULL)   ERROR_EXiT("\n could not malloc data for file");
 
  int elements_read = fread(data, 1, file_length, file);
  int error = fclose(file);
 
  if(error)  ERROR_EXIT("error closing file %s", file_name);
 
  bytes loaded_bytes = {data, data + file_length};
 
  return loaded_bytes;
}

I'd pass back the data and size rather than a begin and end pointer. This makes it clear you didn't allocate memory for end. And data size is usually more useful than an end pointer anyways.

Bytes isn't the best name, but it's not the worst either. Seeing bytes as a data type, I would incorrectly assume it's just a byte[] or such at first glance.

You don't check that fread actually read the bytes, so you could improve your code by making sure fread actually succeeded.

I'd pass back the data and size rather than a begin and end pointer. This makes it clear you didn't allocate memory for end. And data size is usually more useful than an end pointer anyways.

Bytes isn't the best name, but it's not the worst either. Seeing bytes as a data type, I would incorrectly assume it's just a byte[] or such at first glance.

You don't check that fread actually read the bytes, so you could improve your code by making sure fread actually succeeded.

as to size instead of end i am not sure, also as to name bytes

i am not sure too, it is about some chunk of ram, hard to decide what name to use - it should be common name good for common acceptance becouse this is some low level based type

as to fread tnx i moslooked that

i am also not sure if i could give three parts info error or just only one

for example

if(file == NULL) ERROR_EXIT("%s(%d) cannot open file '%s': %s\n", __FUNCTION__, __LINE__, file_name, strerror(errno));

That gives pretty much all the information you need. Giving the source line and the args to the call and the fact that it's indicated failure when there's a failure is useless redundancy, but the reason for the failure is the most useful thing and you're missing it.

Note I also put quotes around the filename so it's obvious it's empty (or contains nonprintable characters). You'll need to include <string.h> and <errno.h> to get the appropriate declarations for strerror() and errno.

but i would like to use one 'global' ERROR_EXIT(...) function for all my erroring purposes (called after all whole program failed function fails and other wrong conditions detected ) - the "strerror(errno)" would then behave correctly? what is scope of this information - only c standard lib? never used it

I would change it slightly, my main issue with the original is that the function call leaves it up-to the caller to free the memory and the allocation is also hard-inlined within the call. Thus there's no way of changing the allocation and the caller may expect the memory to be allocated in a different way and thus free it incorrectly. For example, if the caller tries to release the memory with delete rather than free, the function as is just expects the caller to know what to do. I realise it's a personal project, but 6 months down the line you may be the one who forgets :)

I would change it so the function is passed either an allocator or a buffer object. for example:

(pseudo-code)

int read_file_and_alloc_bytes( MemoryBuffer &buffer, const char *fileName )
{
    buffer.Allocate( file_size );
    return read( buffer.rawBuffer, file_size );
}
 

Which means allocation and release are now managed by the MemoryBuffer object, it also allows the memory buffer to have different implementations with different memory behaviour etc.

n!

I would change it slightly, my main issue with the original is that the function call leaves it up-to the caller to free the memory and the allocation is also hard-inlined within the call. Thus there's no way of changing the allocation and the caller may expect the memory to be allocated in a different way and thus free it incorrectly. For example, if the caller tries to release the memory with delete rather than free, the function as is just expects the caller to know what to do. I realise it's a personal project, but 6 months down the line you may be the one who forgets

I would change it so the function is passed either an allocator or a buffer object. for example:

(pseudo-code)

int read_file_and_alloc_bytes( MemoryBuffer &buffer, const char *fileName )
{
    buffer.Allocate( file_size );
    return read( buffer.rawBuffer, file_size );
}
 

Which means allocation and release are now managed by the MemoryBuffer object, it also allows the memory buffer to have different implementations with different memory behaviour etc.

n!

somewhat good point but this is then some digression because

it is not c ... if so it seems that you can do it simpler by

buffer.read_file("filename.txt");
buffer.free();

in c i got two separate functions instead