Great! your commit is now in the Gnuastro's main `master' branch. Some further corrections were necessary, which I implemented in the next commit. Please go through those points and look at the corrected lines to hopefully prepare you for your next edits in the code ;-).

But as you may have noticed, I just changed the task summary/title, I didn't close it. The reason is that we still need to read-in the full dataset to just read its size. However, as mentioned in the first comment of this task, we don't want this: when only the dataset's metadata is necessary, we shouldn't read the data (and waste time and memory). So to complete this task, we should add some special steps in the arithmetic program so when meta-data are necessary, it doesn't go reading-in the full dataset. For example a special variable/flag called `meta' can be defined in the relevant functions. The  `size' operator (or other later operators) will set it to 1, while the others will set it to zero. When its 1, then the step where we pop the operator (either read it, or just pick it from the stack), we just read/copy the metadata in an empty-of-data dataset.

But this may be a little too low level for you Sachin and isn't a critical issue now. So I recommend moving onto another task/bug. Thanks again for the good work ;-).

Sorry! In the previous point, I should have written: "once you know the dataset's TYPE, ...". I mistakenly wrote "size".

When using `out->array=(void *)&(in->dsize[arg_val-1])` it gives a corruption error. Also using

out->array = malloc( sizeof unsigned long * );
*(size_t *)t.out->array = in->dsize[arg_val-1];

is showing a corruption too. How to store the dimension in the out->array? Or should I store it down in some other variable and pass it to out somehow>

This is good progress indeed. There are just some (mostly minor) points that can be fixed easily but are important:

• What is the `.vscode/settings.json'? Why are the "associations" only defined for three header files? Is it later necessary to do this for all header files? When you add new files, you need to put a comment describing what it is (inside the file itself), and also include a copyright statement (like any other file in Gnuastro ;-)).
• As described in Gnuastro's Coding conventions, "One group of contextually similar functions in a source file is separated from another with 20 blank lines." You have put a nice "size" title with two rows of asterisk above the new operator, but it s only a hand-ful of lines distant from the previous function. In order for the code to be coherent and readable, its necessary that all coders follow the same conventions.
• Similar to the case above, the indentation and positioning of the braces don't follow the GNU standard. Please have a look at some of the other functions to see it in practice.
• This is even visible in a `git diff' on the commandline: lines shouldn't end with white-space characters. Git highlights them in read by default when you use something like this: `git diff master...task-arithop-size').
• Maybe you can change the "size" title (in the asterisk rows) to  something like "metadata". For example later, we might add operators to read the type of a dataset.
• I don't understand why the `out' dataset is allocated with the same size as the input (which can be a large image, thus wasting a lot of memory). The output of this function should just be a single-element dataset (a single number).
• Finally, don't forget to document your new operator ;-) in the Arithmetic Operators section of the book. The source of the book is in `doc/gnuastro.texi' (written in GNU Texinfo). In essence, its just TeX, but with `@' instead of `\'. You can use the documentation of the other operators as a reference.

In the previous post I forgot to mention how you can read the contents of `arg' after doing basic sanity checks.

Again, you can find the way by inspecting other functions, but generally, this is what I usually do: 1) define a new `size_t' variable, maybe `arg_val'. 2) Convert `arg' to the `GAL_TYPE_SIZE_T' TYPE (with the `gal_data_copy_to_new_type_free' function). Note that freeing should only be done if the freeing flag is set. 3) Now that you know the type of the `arg->array' pointer, just read/copy it into the variable with something like this: `arg_val=(size_t *)(arg->array)'. Ofcourse you can also directly read `arg->array' as a size_t array, its just more clear for a reader if you use a clearly-named variable.

For the second argument(the required dimension, let it be called `arg`), I've used `gal_data_t' as well. To use this value, I've used its arg->array, because on inspection it showed a size to be 1, which is desired. But I'm aware it is a void pointer and on dereferencing with a long typecast is showing a large random number. How to fix this? how can I get the value of the second operator?

Also on testing with `during-dev.sh`, it is reported that the `size` is not a valid operator. But the printf debugger works fine and shows all dimensions correctly. I've pushed the repo on GitHub:https://github.com/sachinkumarsingh092/gnuastro/tree/task-arithop-size

Which function to use to read the fits file or its metadata in the lib/arithmetic.c using a filename? I see the functions in the bin/fits/keywords.c to print all the info but how to use them. Is there any funtion to directly read the hdus or fits?

I was getting the following error(in test.log) when I made a small change in the size function. I stashed and removed the directory to my last working commit and this still persists. I looked at the `gsl_fft_complex_wavetable_alloc` it seems to be fine. I did a developer build again but this still persists.


(file #48500)

I've pushed the changes here https://github.com/sachinkumarsingh092/gnuastro/tree/task-arithop-size .

I've, for now, commented the return types and hoping to create something like this. The error I get is that the `size` operator is not being recognized but I'd also like suggestions about the implementation and possible changes.