Bug report for the "type(datetime) function strptime(str,format)"

[GuodingChen]

I have tested the strptime example code:

use datetime_module

type(datetime)  :: date1,date2
type(timedelta) :: timediff

! Example times in "YYYYMMDD hhmmss" format
character(len=15) :: str1 = "20130512 091519"
character(len=15) :: str2 = "20131116 120418"

date1 = strptime(str1,"%Y%m%d %H%M%S")
date2 = strptime(str2,"%Y%m%d %H%M%S")

timediff = date2-date1

print *, timediff
print *, timediff%total_seconds()

My test environment is MacOS, and the compiler is gfortran version: 14.2.0.
The above code can be compiled and run, but it always reports "Program received signal SIGSEGV: Segmentation fault - invalid memory reference."
This is likely due to mismatched string handling — especially around how Fortran interoperates with C in the strptime wrapper. If the strings passed in (str1, format) are declared as character(len=*), Fortran passes them with hidden length arguments, and this can cause issues in interoperability unless handled explicitly.

If c_strptime is written in C or Fortran using ISO_C_BINDING, you must make sure it's correctly defined for character strings. If you’re using character(len=*) without proper binding or copying into C-style null-terminated buffers, you must explicitly convert the strings.

Here is how I fixed this problem, by modifying the code in "type(datetime) function strptime(str,format)" of datetime_module.f90:

  type(datetime) function strptime(str,format)
    ! A wrapper function around C/C++ strptime function.
    ! Returns a `datetime` instance.
    character(*), intent(in) :: str, format
    integer :: rc
    type(tm_struct) :: tm
    character(len=256) :: str_buf, fmt_buf
    ! fixed by guoding chen
    str_buf = trim(str)
    fmt_buf = trim(format)

    rc = c_strptime(trim(str_buf) // c_null_char, trim(fmt_buf) // c_null_char, tm)

    strptime = tm2date(tm)

  end function strptime

For me this completely fixed the problem. AND, it could also be a problem with my system/compiler? I hope this isn't a common problem.

[milancurcic]

Thanks for reporting, I haven't encountered this before, however, I'm not a Mac user. Also gfortran-14.2.0 here, but on Ubuntu. If you compile with full traceback, where does it say that the segfault occurs? I can't say that I understand the difference with the new code.

[GuodingChen]

Thanks for reporting, I haven't encountered this before, however, I'm not a Mac user. Also gfortran-14.2.0 here, but on Ubuntu. If you compile with full traceback, where does it say that the segfault occurs? I can't say that I understand the difference with the new code.

Thanks for attention. I can't say this is a general bug. I use cmake to build and compile without error, but an error occurs when running, the error message is as follows:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x10497ad2f
#1  0x104979d83
#2  0x18ed46de3

As for why the new code can fix this problem, I don’t fully understand it. Here is the answer provided by GPT:
it's not about the length of str vs str_buf, it's about the memory stability and lifetime of the string you pass to c_strptime, Even if str and str_buf have the same length, the problem lies in this expression:
trim(str) // c_null_char

• What went wrong: Temporary strings and memory lifetime:

1. trim(str) returns a new temporary string
2. // c_null_char concatenates a null terminator, creating another temporary string.
3. This new temporary is passed directly to the C function c_strptime.

• But:

1. Fortran does not guarantee that these temporary expressions are stored in memory in a way compatible with what C expects (null-terminated and addressable).
2. If c_strptime stores or accesses the pointer beyond the call boundary (even a tiny bit too long), it may read garbage or cause a segmentation fault.
3. Worse, Fortran might free that temporary string immediately after the call starts — depending on how it's compiled.

• Why this fixed it:

str_buf = trim(str)
rc = c_strptime(trim(str_buf) // c_null_char, ..., tm)

1. str_buf is a named variable with a known, allocated, and stable memory location.
2. Even though trim(str_buf) // c_null_char still creates a temporary, that temporary is built from str_buf, which is in stable memory.
3. If needed, the compiler can optimize or arrange the memory layout more safely around named variables than around temporary results from expressions.

As for why this problem doesn't happen on your machine, I think gfortran-14.2.0 for Ubuntu and MacOS is still different, even if they are the same version. The degree of compilation optimization may also determine such a result. But anyway, since it is possible (small probability), it can also provide reference for relevant users.

[milancurcic]

Can you try the following strptime wrapper and let me know if it works for you?

  type(datetime) function strptime(str, fmt, tz)
    ! A wrapper function around C/C++ strptime function.
    ! Returns a `datetime` instance.
    character(*), intent(in) :: str, fmt
    real(real64), intent(in), optional :: tz
    character(c_char), allocatable, target :: strbuf(:), fmtbuf(:)
    integer :: rc
    type(tm_struct) :: tm
    integer :: n, strlen

    strlen = len_trim(str)
    allocate(strbuf(strlen + 1))
    do n = 1, strlen
      strbuf(n) = str(n:n)
    end do
    strbuf(strlen + 1) = c_null_char

    strlen = len_trim(fmt)
    allocate(fmtbuf(strlen + 1))
    do n = 1, strlen
      fmtbuf(n) = fmt(n:n)
    end do
    fmtbuf(strlen + 1) = c_null_char

    rc = c_strptime(strbuf, fmtbuf, tm)
    if (rc == 0) then
      write(stderr, *) "ERROR:datetime:strptime: failed to parse string: ", str
      return
    endif
    strptime = tm2date(tm, tz)
  end function strptime

[GuodingChen]

Thanks for effort. YES, it works for me now, however, with minor modify:

write(stderr, *) "ERROR:datetime:strptime: failed to parse string: ", str

--->

write(*, *) "ERROR:datetime:strptime: failed to parse string: ", str

and

strptime = tm2date(tm, tz)

----->

strptime = tm2date(tm)

Otherwise, a compilation error will occur.