bug#67711: Org Babel gives incomplete result when writing multi-thread code

bug#67711: Org Babel gives incomplete result when writing multi-thread code

[. shynur]

(I use Emacs v29.1.90 for MS-Windows; gcc 10.3.0)
Here's an Org file:

    #+BEGIN_SRC C
    #include <stdio.h>
    #include <omp.h>
    int main() {
    #pragma omp parallel num_threads(3)
        printf("0"), printf("1");
    }
    #+END_SRC

    # Local Variables:
    # eval: (require 'ob-C)
    # org-babel-C-compiler: "gcc.exe  \
    #                         -std=c17 -Wall -O0  \
    #                         -fopenmp "
    # org-confirm-babel-evaluate: nil
    # End:

Executing the C code block usually outputs:

    #+RESULTS:
    : 10101

    #+RESULTS:
    : 1101

This output was unexpected, so I personally ran the temporary EXE file generated by Org-Babel:

    Windows Terminal
    PS D:/Tmp/babel-Xyz123> ./C-bin-Xyz123.exe
    010101

As you can see, this program should output 6 characters.

bug#67711: Org Babel gives incomplete result

[. shynur]

I found that the leading '0's of result will always be trimmed,
so `010101` will be printed as `10101`.

It seems to be a feature?
If so, I think this is reasonable and convenient.
But how can I disable it?

bug#67711: Org Babel gives incomplete result

[Eli Zaretskii]

> From: ". shynur" <one.last.kiss@outlook.com>
> Date: Fri, 8 Dec 2023 14:45:25 +0000
> msip_labels: 
> 
> I found that the leading '0's of result will always be trimmed,
> so `010101` will be printed as `10101`.
> 
> It seems to be a feature?
> If so, I think this is reasonable and convenient.
> But how can I disable it?

I think this is a question for Org developers.

bug#67711: Org Babel gives incomplete result when writing multi-thread code

[Eli Zaretskii]

> From: ". shynur" <one.last.kiss@outlook.com>
> Date: Fri, 8 Dec 2023 14:31:37 +0000
> msip_labels: 
> 
> (I use Emacs v29.1.90 for MS-Windows; gcc 10.3.0)
> Here's an Org file:
> 
>     #+BEGIN_SRC C
>     #include <stdio.h>
>     #include <omp.h>
>     int main() {
>     #pragma omp parallel num_threads(3)
>         printf("0"), printf("1");
>     }
>     #+END_SRC
> 
>     # Local Variables:
>     # eval: (require 'ob-C)
>     # org-babel-C-compiler: "gcc.exe  \
>     #                         -std=c17 -Wall -O0  \
>     #                         -fopenmp "
>     # org-confirm-babel-evaluate: nil
>     # End:
> 
> Executing the C code block usually outputs:
> 
>     #+RESULTS:
>     : 10101
> 
>     #+RESULTS:
>     : 1101
> 
> This output was unexpected, so I personally ran the temporary EXE file generated by Org-Babel:
> 
>     Windows Terminal
>     PS D:/Tmp/babel-Xyz123> ./C-bin-Xyz123.exe
>     010101
> 
> As you can see, this program should output 6 characters.

The above invocation is AFAIU not an accurate reproduction of what
happens when this program is invoked from Emacs on MS-Windows.  Emacs
on Windows communicates with subprocesses via pipes, so a more
accurate reproduction would be something like

   C-bin-Xyz123.exe | more

IOW, you need to invoke the program with its output redirected to a
pipe.

In any case, please report this to the Org developers first, and only
if their analysis shows this is a core Emacs problem, come here.

Thanks.

bug#67711:

[. shynur]

> In any case, please report this to the Org developers first, and
> only if their analysis shows this is a core Emacs problem, come
> here.

Understood.  (I sent it here because the file ‘ob-C.el’ says “This
file is part of GNU Emacs.”)

bug#67711:

[Eli Zaretskii]

> From: ". shynur" <one.last.kiss@outlook.com>
> CC: "67711@debbugs.gnu.org" <67711@debbugs.gnu.org>
> Date: Fri, 8 Dec 2023 14:56:12 +0000
> msip_labels:
> 
> > In any case, please report this to the Org developers first, and
> > only if their analysis shows this is a core Emacs problem, come
> > here.
> 
> Understood.  (I sent it here because the file ‘ob-C.el’ says “This
> file is part of GNU Emacs.”)

Org is indeed part of Emacs, but is developed by a separate team, and
has its own forums for reporting problems.