Investigate *_new() functions

[flatcap]

Recently, @ossilator pointed us to the nf (no-fail) functions in isync.
These functions will never return NULL, they'll stop the program instead.

That got me thinking about which NeoMutt functions could follow this model.
The memory functions already do this, but they're not documented as such.

There are 141 "_new()" functions that allocate memory.

• Can any of these functions fail?
• Can they be refactored so they always succeed?
• Can we replace all the if (!ptr) checks with assert(ptr)?

Your help would be appreciated with this "investigation" task.

• Have a quick look
• Have a think
• Ask some questions

Then we can decide if we'd like to refactor the code.

Thanks!

[flatcap]

89 _new() functions contain a malloc function:

account_new address_new alias_new attachmatch_new attach_data_new attach_private_data_new attr_color_new bdb_sdata_new browser_private_data_new buf_new cbar_data_new chain_data_new cid_map_new completion_data_new compose_shared_data_new cs_new cs_subset_new curses_color_new email_new enter_state_new env_wdata_new group_new hash_new hcache_new helpbar_wdata_new ibar_data_new imap_adata_new imap_edata_new imap_mdata_new index_private_data_new index_shared_data_new lmdb_sdata_new lookup_new lz4_cdata_new mailbox_new mailcap_entry_new maildir_edata_new maildir_entry_new maildir_mdata_new mbox_adata_new menu_new message_new monitor_new msgwin_wdata_new mutt_actx_new mutt_addr_new mutt_aptr_new mutt_autocrypthdr_new mutt_autocrypt_db_account_new mutt_autocrypt_db_gossip_history_new mutt_autocrypt_db_peer_history_new mutt_autocrypt_db_peer_new mutt_body_new mutt_env_new mutt_param_new mutt_pattern_list_new mutt_pattern_new mutt_regexlist_new mutt_regex_new mutt_replacelist_new mutt_seqset_iterator_new mutt_socket_new mutt_window_new mview_new mx_msg_open_new neomutt_new nm_adata_new nm_edata_new nm_mdata_new nntp_adata_new nntp_edata_new notify_new pager_private_data_new parameter_new pbar_data_new pop_adata_new pop_edata_new progress_wdata_new qstyle_new regex_color_new regex_new remailer_new rocksdb_sdata_new sbar_data_new sb_wdata_new slist_new url_new zlib_cdata_new zstd_cdata_new

52 _new() functions don't contain a malloc function:

alias_dialog_new alldialogs_new attach_new browser_sort_count_new cbar_new cmd_new compare_stat comp_msg_open_new env_window_new find_next_mailbox helpbar_new ibar_new imap_msg_open_new index_window_new ipanel_new maildir_email_new maildir_msg_open_new maildir_update_flags mbox_has_new mbox_msg_open_new menu_window_new mh_msg_open_new mix_dlg_new msgcont_new msgwin_new mutt_actx_add_fp mutt_conn_new mutt_gsasl_client_new mutt_hash_int_new mutt_hash_new mutt_prepare_template mutt_sasl_client_new nntp_active_fetch op_main_next_new op_sidebar_next_new op_sidebar_prev_new op_toggle_new pager_window_new pbar_new ppanel_new progress_new progress_window_new query_dialog_new read_headers_fetch_new rootwin_new sbar_new sb_next_new sb_prev_new simple_dialog_new thread_is_new win_chain_new win_hosts_new

[roccoblues]

So, I looked through the *_new()functions. By far the vast majority seems safe. Most of them just do mutt_mem_calloc(), followed by a couple of field initializations.

Here a the ones I found that can fail:

conn/socket.c: mutt_socket_new
mutt/regex.c: mutt_regex_new
mx.c: mx_msg_open_new
notmuch/mdata.c: nm_mdata_new
color/curses.c: curses_color_new
config/regex.c: regex_new‎
imap/command.c: cmd_new

[flatcap]

Thanks!
It seems that _new() is a bit overloaded:

• Primitive: alloc some memory
• Complex: alloc and initialise
• Compound: call another new/alloc function and initialise

[roccoblues]

yeah, plus:

• regexp compile
• curses init
• socket init

[flatcap]

OK, this doesn't seem to lead anywhere.
Thanks, anyway!